[p4] Sharing client spec between users

johan.nilsson at esrange.ssc.se johan.nilsson at esrange.ssc.se
Wed Dec 5 00:49:52 PST 2001


Ok,

let's explain this a bit better. The project in question is in-house
software targeted to OpenVMS on the Alpha platform. There are several
applications on the machine, each one consisting of a number of
subcomponents (exe's, lib's, ...) which are located a subdirectory of the
main application. For using (and maintaining) each application, there is a
separate user account named after the application (e.g. APP1). What we'd
like to do is to keep two versions of each application, TEST and PROD online
(the intentions for these are pretty obvious). For historic reasons, the
organization of these on-disc looks somewhat as follows:

DISK$USER:[APP1]		// App 1 root directory
DISK$USER:[APP1.COMPONENT1]	// App 1 component one source
DISK$USER:[APP1.COMPONENT2]	// -"- 2
DISK$USER:[APP1.BIN]		// App 1 executables
DISK$USER:[APP1.SETUP]		// App 1 configuration

We intend (and are testing) to change this to:

DISK$USER:[APP1.TEST]			// App 1 root directory (TEST)
DISK$USER:[APP1.TEST.COMPONENT1]	// App 1 component one source (TEST)
...
DISK$USER:[APP1.PROD]			// Appl 1 root directory (PROD)
...

For Perforce, I'm considering the following mapping:

//depot/app1/main/...	//client/app1/test/...
//depot/app1/relX/...	//client/app1/prod/...

The code line 'app1/main/...' will be branched to 'app1/relX/...' for
maintenace only (where X is the version) upon release and the view mapping
for //client/app1/prod/... will need to be changed in applicable client
specifications. That's why I'd like to share a client spec (for each
application) between different users, inorder to avoid maintenance
headaches. Of course, maintaining a proper release procedure should lessen
the chances of getting into trouble.

The users need to log onto the application (e.g. APP1) account on the target
system, but the will have separate Perforce identities (which currently are
setup using batch files, including P4USER, etc...). 

Agreed, the overall organization of this might not be the very best, but the
development of the software started some ten years ago and it's got a quite
few dependencies involved that aren't really easy to sort out if we start
reorganizing the stuff. The reason we're investigating this now is that
there's a need to extend the application(s) during the next year and we'd
like to put the stuff under version control before that.

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.

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?

* 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).

// Johan

> -----Original Message-----
> From: steve at vance.com [mailto:steve at vance.com]
> Sent: den 4 december 2001 09:41
> To: johan.nilsson at esrange.ssc.se; perforce-user at perforce.com
> Subject: Re: [p4] Sharing client spec between users
> 
> 
> The first question has to be "Why?"  If there isn't a 
> compelling reason or sufficient constraints to address the 
> negatives, don't do it.
> 
> That said, it can be done.  You will have the issues of 
> both users editing the same file.  You will also have the 
> interesting effect that the two users will have different 
> default changelists, even in the same workspace.
> 
> If part of the motivation is to avoid a single user having 
> to switch identities or clients, you can use the P4CONFIG 
> mechanism to simplify the process.
> 
> Your later mention about using +l won't do anything for 
> you.  It only affects locking at the depot level, not at 
> the host OS level.  I won't prevent mutual editing of the 
> file.
> 
> Basically, if the usage is read-only or if the two users' 
> usage is exclusive either by time (using changelist 
> creation/submission as the transaction boundaries) or by 
> source (i.e. they use entirely different directories) and 
> you're not concerned about cross-contamination due to 
> syncs, you can do it safely.
> 
> If you want a safer approach to the source exclusive 
> scenario, put two clients, each for a subset of the source, 
> under a directory tree that reflects the whole space.  A 
> safer approach to time exclusivity is just to create 
> different workspaces.  If it's about disk space, just use 
> separate clients.
> 
> Steve
> 
> > Hi,
> > 
> > supposing two different users are working on the same 
> machine, can they
> > share a common client specification? If possible, are 
> there any problems to
> > be aware of?
> > 
> > // Johan
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-
> user
> > 
> 
> 
> ---------------------------------------------
> This message was sent using WebMail by CyberGate.
> http://www.gate.net/webmail
> 
> 



More information about the perforce-user mailing list