[p4] getting a true "client view" of the depot - Stephen Vance - com.perforce.perforce-user

13 messages in com.perforce.perforce-user[p4] getting a true "client view" of ...

From	Sent On	Attachments
Steve James	14 May 2001 15:42
Russell C. Jackson	14 May 2001 16:13
Gordon Broom	14 May 2001 16:27
Chuck Karish	14 May 2001 17:33
Simon Morton	14 May 2001 17:37
Chuck Karish	14 May 2001 18:18
Dave Lewis	14 May 2001 19:40
Robert Cowham	15 May 2001 01:21
Rick Macdonald	15 May 2001 06:36
Stephen Vance	15 May 2001 08:17
Laura Wingerd	15 May 2001 08:35
Chuck Karish	15 May 2001 10:03
Stephen Vance	15 May 2001 10:34

Subject:	[p4] getting a true "client view" of the depot
From:	Stephen Vance (ste...@vance.com)
Date:	05/15/2001 10:34:10 AM
List:	com.perforce.perforce-user

At 10:04 AM 5/15/2001 -0700, Chuck Karish wrote:

At 11:17 AM 5/15/2001 -0400, Stephen Vance wrote:

At 05:33 PM 5/14/2001 -0700, Chuck Karish wrote:

At 03:42 PM 5/14/2001 -0700, Steve James wrote: It is a straightforward task to manage your users' p4 metadata so that only the correct versions of the interesting files are shown.

A strategy that's natural for p4 would be for each user to have a separate client specification (with its own client root) for each project. The per-project refresh script would update the appropriate client to the official view for that project and sync that client's workspace to the current label for that project. If the official client view includes only the files that are used for the project, p4win will do the right thing if it uses the appropriate client.

You're correct on the strategy. But the complexity and volatility of the environment will determine how straightforward it really is. A highly componentized code base without much hierarchical organization (read: libraries and packages) could be a real nightmare to manage in this way, particularly if they are being added and deleted regularly and projects aren't insulated from each other with branches.

If projects aren't insulated from each other with branches you're in trouble no matter how you display the file structure to your users. Some sort of branching is necessary as soon as someone has to modify a file that's being used at a revision other than the head.

If the libraries are really libraries, treat them as black boxes and don't make their source part of the project.

I agree that this is a desirable treatment, but not always appropriate to the circumstance. If, for example, your development target is a set of three .jar files for Java distribution, they are effectively libraries, but can't be treated as binary.

Libraries obtained from a third party and mature or unchangeable can be treated in the manner you suggest. Libraries that are the object of development, either for distribution or as part of the organizational hierarchy of the development environment, can only be treated that way if the organization has strictly defined the library boundaries as project boundaries for work allocation.

Steve