[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 08:17:14 AM
List:	com.perforce.perforce-user

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

At 03:42 PM 5/14/2001 -0700, Steve James wrote:

One of the weakest aspects of Perforce, IMHO, is it's lack of a true "client view" in its GUI tool.

Here's the problem. Let's say your code base is highly componentized, and a developer working on some project/product is using lots of these components, and they are all over the place in the p4 hierarchy, some on branches, some on mainlines, etc. We have forced developers to sync using a script that can figure out where to get these components from, and what branches/labels to use, etc. If they look on their disk, they'll see all these components gathered together as peers in some directory, very orderly. But they see nothing like that in P4Win.

What I want, of course, is something more akin to ClearCase, and a developer's view of the world for some particular project is focused on the pieces as they exist in that workspace, not as they exist in the depot. Revision history, checkin/out, etc, all work on the "mapped" workspace view, not on the depot view. Of course I'd like to be able to toggle between "mapped workspace" view and raw depot view, just like I can toggle today between viewing the entire depot vs the subset I have mapped.

It seems that this is not a great departure from where p4win is today; it's really just that one tree control that would need to be changed. I'd hate to rewrite a tool just for that one change. What do people think, would you use such a feature?

This would be a huge departure from the p4 abstraction. ClearCase can accomplish this sort of remapping because it implements its own filesystem (or the practical equivalent thereof). Doing such remapping only in p4win would break correspondence to the file hierarchy seen by the command line tool.

It's not really a departure from the abstraction. Perforce defines three views that you can use interchangeably: depot view, client view, and local file system view. It just so happens that P4Win only implements the first two for most purposes.

The reason you can use them interchangeably is because the client spec defines a one-to-one mapping between a) the depot and the client, and trivially b) the client and the local file system.

All of the command line tools can take file names in any of these three name spaces. After all, you don't have to say 'p4 edit //<client spec>/mydir/myfile.html'. You can simply say 'p4 edit myfile.html' from the correct directory.

The trivial mapping between the client view and the local file system view should make display in P4Win as complicated as it takes to display all of the vagaries of multiple drive mappings in client views.

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.

Steve