[p4] Sharing client spec between users

Robert Cowham robert at vaccaperna.co.uk
Tue Dec 4 04:54:09 PST 2001


> What I meant was to actually use the same client specification for two
> separate users, that maps to the same physical machine (doesn't
> really sound
> like a good idea, does it).

Errrr no (even worse)!!

>
> I'm only playing around for the time being, but I currently have two
> separate client specifications (which in fact are identical regarding the
> view(s)) for the users. The client specifications should always remain
> identical to each other (but will change upon product release), so I was
> just thinking I might save me myself some maintenance problems and use a
> single spec for both users. This is a pretty special situation where the
> target system will always be the same as the development system (in-house
> application).
>
> You really made a point about editing the same file at the same time -
> thanks. However it is very unlikely that they will be working
> with the same
> application at the same time, so perhaps using the lock (+l?)
> qualifier for
> all files would be a viable solution.

There are 3 options:

1. If they are in different client workspaces the standard PErforce
mechanisms for detecting and resolving conflicts would be fine (p4 edit
gives you a warning if someone else has opened the file). The second person
to submit needs to resolve the conflict (check docs for details)

2. Remember that you can lock a file currently opened for edit (p4 lock)
which prevents other users from submitting their changes but doesn't stop
them from opening for edit.

3. The filetype +l (p4 help filetypes) only allows one person to open a file
for editing at a time (and is thus more restrictive than p4 lock).

Generally I would recommend people to use option 1 (optimistic locking).
Only if you get problems, or have binary files where resolving conflicts is
either difficult or impossible would I go for 2 or last case 3.

When files are locked (using 2 or 3) it can cause as many problems as it
solves. Someone goes to lunch at the wrong time, goes home early, goes on
holiday, leaves the company with a locked file - without administrator
rights you can be severely inconvenienced by any of these and people under
tight deadline pressures occasionally make temporary copies and changes and
then later forget to check them in...

It is not difficult to write a Perl or Python script to keep an eye on a
couple of client workspace specs and email people if  one is updated and the
other not.

Just some thoughts.

Robert





More information about the perforce-user mailing list