[p4] [Newbie]: Mapping one depot to multiple locations in same workspace
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.)
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
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