[p4] mapping 1 area of depot to multiple areas of workspace

[Weintraub, David]

Any feature found in VSS and is not in another version control system is
a plus for the other version control system ;-).

A lot of features in Visual SourceSafe are very poorly implemented and
the way it does code sharing is one of them. There is no distinction in
any of the directories that share the code, and sharing is done on a
file level. I don't even know of a command that will even go through the
source archive, find all of the files that are shared, and where they
are located. Maintaining it becomes a big giant mess.

ClearCase does use softlinks, but does a very strange thing to prevent
multiple edits: If you checkout a softlink, the related files will
silently disappear from the other directories in your view. This
prevents the problems of multiple checkouts, but can cause some concern
among developers when they attempt a build and the build fails because
files simply disappear.

I also think that this sharing is rather sloppy in other ways. First of
all, you can only do this inside of a single VOB (and projects can
contain multiple VOBS). Plus, you specify it on a file by file basis.
This encourages sloppy code sharing.

Subversion has the best implementation of this feature. Let's say you
have a project with the URL of "svn://subserver/projects/trunk/foo", and
this project is dependent upon files located in
"svn://subserver/dependencies/trunk/bar". In Subversion, you attach an
svn:externals property to the "foo" directory with the URL of the "bar"
project. When you download "foo", it automatically downloads "bar" as a
subdirectory of "foo".

There's quite a bit to like about this method: The dependent directories
are read only and you cannot submit changes in those files to the
Subversion archive. If you really want to change these files, you have
to checkout the project directly. Subversion also does this on a
directory to directory basis. You cannot simply pick and choose the
files. This causes you to think more modularly.

Also, since this is specified as a property on a directory, and
properties are versioned, the relationship is also versioned. One
version of "foo" can depend upon "bar" while the next version of foo can
depend upon "fubar". And, even better, you can specify specific versions
of the dependent project. For example, "foo" is dependent upon REL_1.0
of "bar". The developers who maintain "bar" can continue their
development without worrying about affecting other projects.

Perforce's view only defines the depot to workspace mapping, and doesn't
specify any attributes that might be attached to this mapping. So, if
you had write access to a particular file and if Perforce allowed
multiple downloads of that file, you end up with the problems I
mentioned in my other email. You could solve this issue if Perforce's
client allowed you to specify that you want to map a particular set of
files as "read-only". It would also be nice to specify a specific
versions of these read only mappings too. That way, I can specify a
particular version instead of depending upon the latest copies.

Still, there are several ways around this problem. If you're on Unix,
you can implement symbolic links. The problem is that these links are
file based and not archive based. Another thing you can do is implement
a "client" within a "client". That is, you have foo mapped as:

	Client: myfoo
	Root: C:\p4clients\foo

	View:
		//depot/proj/foo/MAIN/...	//myfoo/...

Then define a client:

	Client: mybar
	Root: C:\p4clients\foo\bar

	View:
		//depot/dependent/bar/MAIN/...	//mybar/...

When you sync both clients, the "bar" files are under "foo". Not very
smooth, but it does work. And, if you've setup P4CONFIG, and setup your
config files, your Perforce client changes automatically based upon the
directory you're in. If you go to C:\p4clients\foo\bar, you're using
Client "mybar". When you're in C:\prclients\foo, you're using Client
"myfoo".

-----Original Message-----
From: Edil Cadenas [mailto:Edil.Cadenas at ktd-kyocera.com] 
Sent: Wednesday, October 11, 2006 4:38 PM
To: Weintraub, David; perforce-user at perforce.com
Subject: RE: [p4] mapping 1 area of depot to multiple areas of workspace

Hi David,

As I have explained to Steve (Vance) earlier, the way our software
release is configured is that some modules have common files/modules.

Each workspace is an actual representation of the software product
release (directory structure and all).  In VSS, this is easy to achieve
because of the soft links feature.  This also holds true for ClearCase.

Because there's no soft links in Perforce, I can't have a environment
where the common files can be shared among the affected modules.

Having multiple workspaces for one product release will make it harder
to maintain for our release/build team as they would need to handle
several products.

Best regards,
Edil

 

-----Original Message-----
From: Weintraub, David [mailto:david.weintraub at bofasecurities.com]
Sent: Wednesday, October 11, 2006 1:11 PM
To: Edil Cadenas; perforce-user at perforce.com
Subject: RE: [p4] mapping 1 area of depot to multiple areas of workspace

What happens when you edit a file in this workspace? Do both copies get
updated, or just one? How would it work? Could you have two versions of
the same file? Would it be possible to open each version?

One of the things Perforce has to enforce is a one-to-one mapping of a
depot file to a particular file in the workspace, or you get the type of
complications above.

Why not simply create two views?

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Edil Cadenas
Sent: Wednesday, October 11, 2006 2:53 PM
To: perforce-user at perforce.com
Subject: [p4] mapping 1 area of depot to multiple areas of workspace

Is it possible to map 1 area of the depot to several areas of the
workspace?

e.g.

      //depot/dir1/...    //Workspace/local1/...

      //depot/dir1/...    //Workspace/local2/...

 

I understand that the branch mechanism somehow provides a way to do that
but does it on the depot side.  What I would to do is to just map the
same are of the depot to several sections of my workspace.  I tried
using the "+" mapping but I always end up getting the second line only.

 

Is what I'm trying to actually possible in Perforce?  Thanks for
anyone's help.

 

 

Best regards,

Edil

 

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user