[p4] [Newbie]: Mapping one depot to multiple locations in same workspace

Philip Panyukov ppanyukov at googlemail.com
Tue Mar 31 10:41:14 PDT 2009

Yes that's right, I was referring to branch specs, not client views.
But this was done only to highlight that the limitation of
"one-to-one" mapping exists in other places besides client views.

To answer Jeff's question of "When you need to push to a sixth
project, will you use that proposed branch-spec? More importantly,
will you remember to push only to the sixth project, avoiding
inadvertently repopulating the original five projects?".

I would say the answer is "Most likely yes".

The reason for that is that Perforce will (most likely) say "all
revisions are integrated" for projects 1 to 5, and only project 6 will
show up as needing integration.

The more real scenarios for me would be:

1. I am working on project X, Y and Z. I want to ensure I am using the
latest set of tools. To make sure I do, run p4 integrate -b TOOLS
//projectX/... //projectY/... //projectZ/....

2. If I were someone overseeing general development activities within
organisation, I would want to know: are there projects which use
out-of-date versions of tools?  If so, make sure those projects
migrate to new version at some point.  With one global branch-spec, I
would just "p4 interchanges -b TOOLS" and the answer is there. With
current capabilities, I have to go through each branch-spec etc etc.
Doable, but not so elegant.

This applies to many things, not just tools. These are libraries,
dependencies and things like this.  In fact, libraries and
dependencies are of more concern to me than tools.

The client views and "one-to-many" mappings are of course more tricky
but even here there were times I briefly wished it was possible. Don't
remember what it was exactly but it always was "use same file in
multiple places without branching" type of thing.  The dangers of such
mappings in client views are probably no greater than having sparse
branches.  May be confusing, but only if files are edited and
submitted, but probably perfectly fine for libraries, dependencies,
tools and such.  I can perfectly see the use of such feature.


2009/3/31 Ivey, William <william_ivey at bmc.com>:
> I believe Philip is talking about branch specs and not client views,
> so the ability to do mappings like that would have some utility and
> only limited issues. Of course it only works when you name the
> destination, or if you could use it to "broadcast" an integration.
> (I've had cases where that would have been useful.)
> -Wm
> -----Original Message-----
> From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Rick Macdonald
> Sent: Tuesday, March 31, 2009 9:00 AM
> Here's my guess:
> If you open //tools/NAnt/doit for edit, I think Perforce only stores the
> fact that the file is open on the named clientspec (workspace). Which
> one would that be? There are three to choose from. Which one gets its
> file permissions changed to read-write if you open with depot syntax
> instead of local file syntax? Removing the ability to use depot syntax
> to support this would be a bit messy, I think.
> The opposite case is similar: mapping multiple depot directories to one
> local disk directory. If you add a file using local disk syntax, it
> wouldn't know which area of the depot to add the the file to.
> I have a ton of shared tools, but they are in a shared development area
> available to all projects, usable by execution "PATH" or by well-known
> location that includes an environment variable override for the path
> prefix. I'm sure you have a good reason not to do this. I'm glad I
> don't!  ;)
> Rick
> Philip Panyukov wrote:
>> I too found this to be a limitation is some cases.  One recent one was
>> to set up one single branch spec for all the tools we use in all
>> projects and then use that spec to integrate new versions of tools
>> into projects.
>> TOOLS branch
>> //tools/NAnt/... //projA/tools/NAnt/...
>> //tools/NAnt/... //projB/tools/NAnt/...
>> //tools/NAnt/... //projC/tools/NAnt/...
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list