[p4] Sharing client spec between users

Stephen Vance steve at vance.com
Wed Dec 5 15:16:18 PST 2001


At 09:49 AM 12/5/2001 +0100, johan.nilsson at esrange.ssc.se wrote:
>There's a very good chance that we can live with not having more than one
>developer working on the same application at the same time, as this has been
>the normal way of working for some time now (and not so many developers know
>OpenVMS). But of course - allowing parallel development would definitely be
>the preferred choice.

If that's the preferred choice, I would recommend different clients.  You 
could even set per-user logicals so that the client spec was the same for 
each but the client name was different and it maps to separate physical 
disk space.

>Follow-up questions from your response:
>
>* What's the issue with sync's - are they user dependent or what? What do
>you mean by cross-contamination?

The issue is two-fold: 1) if the two users share components and their 
component dependencies are not strictly the same, you can have a 
competition over which component source is synced at any given time leading 
to risk of errors, and 2) if the two users are working simultaneously, one 
user may want to keep things static before syncing until they can fix the 
bug, finish the enhancement, etc.  These two are really macro and micro 
versions of the same idea.

>* As for using the +l qualifier - if another user tries to p4 edit a file to
>the same location, he should get an error message, or? On the other hand, if
>he simply opens it into an editor before opening it for edit in perforce,
>there will be problems (but changes will not be entirely lost as VMS has
>built-in versioning of files - it will just require some manual merging
>afterwards).

The message he would get is probably "file is already open" rather than 
"file is locked."  Check this to be sure.  Regardless, it is still writable 
to him unless file system permissions prevent it, which if it is being 
shared by the different users, they can't.  He can therefore edit it 
despite its not being in the changelist he owns, he can't check it in (its 
not in his changelist), he has now contaminated the change the other 
developer is working on, and there is always the possibility of 
simultaneous edits.  VMS versioning can mitigate this, but if it was a 
sufficient solution, you wouldn't need Perforce.  My guess is you would 
rather not have to resort to that facility to resolve your conflicts.


>// Johan

Stephen Vance
mailto:steve at vance.com
http://www.vance.com/




More information about the perforce-user mailing list