14 messages in com.perforce.perforce-user[p4] Sharing client spec between users| From | Sent On | Attachments |
|---|---|---|
| joha...@esrange.ssc.se | 04 Dec 2001 02:14 | |
| Arnt Gulbrandsen | 04 Dec 2001 03:13 | |
| Robert Cowham | 04 Dec 2001 03:38 | |
| joha...@esrange.ssc.se | 04 Dec 2001 04:02 | |
| Robert Cowham | 04 Dec 2001 04:53 | |
| ste...@vance.com | 04 Dec 2001 08:40 | |
| Priamos Georgiades | 04 Dec 2001 10:11 | |
| Stephen Vance | 04 Dec 2001 19:03 | |
| joha...@esrange.ssc.se | 05 Dec 2001 00:49 | |
| Jeff A. Bowles | 05 Dec 2001 07:49 | |
| Stephen Vance | 05 Dec 2001 15:15 | |
| joha...@esrange.ssc.se | 06 Dec 2001 00:13 | |
| Robert Cowham | 06 Dec 2001 01:30 | |
| PPry...@factset.com | 10 Dec 2001 08:43 |
| Subject: | [p4] Sharing client spec between users |
|---|---|
| From: | Robert Cowham (rob...@vaccaperna.co.uk) |
| Date: | 12/04/2001 04:53:47 AM |
| List: | com.perforce.perforce-user |
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