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

Ivey, William william_ivey at bmc.com
Tue Mar 31 09:10:23 PDT 2009

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


-----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!  ;)


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/...

More information about the perforce-user mailing list