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

Gabor Maghera gmaghera at gmail.com
Tue Mar 31 10:57:57 PDT 2009

Tobias, as far as I know, doing a one-to-many client mapping only works for
mapping multiple depot locations to one local workspace location (that's
where using '+' comes in).  You are trying to go the other way in your
example.  Perforce keeps track of what files a client has synced; supporting
one depot path mapped to multiple location on the filesystem would probably
require additional logic in the tool.


On Tue, Mar 31, 2009 at 10:41 AM, Philip Panyukov
<ppanyukov at googlemail.com>wrote:

> 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.
> Philip
> 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
> >
> _______________________________________________
> 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