16 messages in com.perforce.perforce-user[p4] Perforce pseudouser licenses - A...
FromSent OnAttachments
John...@sophos.com28 Apr 2005 09:40 
Ivey, William28 Apr 2005 11:44 
jab28 Apr 2005 12:38 
Jamison, Shawn28 Apr 2005 15:03 
Dave Lewis28 Apr 2005 15:34 
Arnt Gulbrandsen28 Apr 2005 20:10 
Knight, Steve29 Apr 2005 02:40 
Dani...@nokia.com29 Apr 2005 04:04 
Dave Lewis29 Apr 2005 10:06 
Noel Llopis02 May 2005 13:25 
wmur...@agl.com.au02 May 2005 16:19 
John...@sophos.com04 May 2005 08:20 
Arnt Gulbrandsen04 May 2005 11:40 
Lee Marzke05 May 2005 07:18 
Ivey, William05 May 2005 08:21 
Mark Harrison05 May 2005 10:34 
Subject:[p4] Perforce pseudouser licenses - Argh!
From:Knight, Steve (Stev@kbcfp.com)
Date:04/29/2005 02:40:59 AM
List:com.perforce.perforce-user

Oops replied to the wrong mail before. Need more coffee ...

Steve

-----Original Message----- From: perf@perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Knight, Steve Sent: 29 April 2005 09:50 To: perforce-user at perforce.com Subject: RE: [p4] p4 proxy

We had a similar issue which I discussed at length with Perforce. It basically distilled to this:

We could setup a single build user with 'open' only permissions to the depot (so it can label stuff) and all automated builds and release scripts use this single user to build stuff by creating project level release scripts. Clearly this user is not password protected because there would be little point. I mentioned that this would be hard to manage if we were trying to enforce chinese walls around our repository (because everyone can see everything thru the build user) but it turned out that our particular perforce server configuration didn't make this an issue.

I then asked how I could do checkpoints without doing them as myself, which is crazy, and without opening the permissions of the unprotected build user up to admin. They relented and said I could have a pseudo license for that too. So I've got, or am about to get, two.

Seems to me like their licensing model/permissioning system needs a bit of work. I think we should be able to have as many users with 'open' permission as we want but only pay for the 'write' ones. I'd even be willing to pay a higher price for the 'write' licenses to make this work. Then we could have a single pseudo account for admin and all would be good. Either that or floating licenses, but it's difficult to see how that would work for Perforce.

-----Original Message----- From: perf@perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Grills, Jeff Sent: 28 April 2005 23:04 To: Sundy, Mike; perforce-user at perforce.com Subject: RE: [p4] p4 proxy

If you're facing that much data, I think it would be worth building an application that does the sync but doesn't store the file out to disk. As I've said, using the P4 API, it would be relatively trivial (just ignore the OutputText and OutputBinary callbacks). I don't really know the Perl, Ruby, or Python integrations very well, but I would expect that they're basically an integration of the P4 API into those languages, which would mean that it should be relatively simple to do it in those languages as well.

Maybe when I finish my p4 client service utility that I'm working on, and if I remember, I might crank this little utility out.

-----Original Message----- From: Sundy, Mike [mailto:MSundy at maxis.com] Sent: Thursday, April 28, 2005 4:50 PM To: Grills, Jeff; perforce-user at perforce.com Subject: RE: [p4] p4 proxy

Yes, but at least this way you don't have to store tens of GB's of data on the client just to pull the files onto the proxy. Some of our client workspaces are 80 GB so it is nice if we don't have to store that large amount of data on a client in order to cache the proxy. It looks like a script is required here to get around the 'full sync every time' issue that you mentioned.

-----Original Message----- From: Grills, Jeff [mailto:jgrills at soe.sony.com] Sent: Thursday, April 28, 2005 10:38 AM To: Sundy, Mike; perforce-user at perforce.com Subject: RE: [p4] p4 proxy

I gave this a quick little test, and it does appear to download the files to the client, so I'm pretty confident that it will update the proxy. However, the client never updates the DB with the file it received since it failed to write it. That means that every sync is effectively a full sync. You could probably work around this by polling the change counter, sync'ing to that number, and then flushing to that number. That's not much cleaner than doing a sync and then rm -rf'ing the files, though.