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

Jeff A. Bowles jab at pobox.com
Tue Mar 31 12:40:09 PDT 2009

I am going to respond to this from a specific perspective: "project B nerd."
Here goes:

"my group started working on project B, nine (9) weeks ago. We have used the
tools that were populated with the initial branching of project B/... and
are really happy with our progress.  We *absolutely* do not want a 'push' of
any changes to the common tools or common libraries, at least not pushed
into our area. We want to schedule that after we've had some time to
evaluate it."

A really nice thing about the "pull when you're ready" philosophy, is that
you can work in your workspace very happily - until you decide to retrieve
(a.k.a. 'get revision' or 'sync') later work.  It is a completely static
environment, meaning that the tools or other SCM-provided things aren't
changing without an explicit action on your part. (Laura Wingerd uses the
term, 'jello views', to describe that other way -- it's not evil, but it can
force you to constantly do the game of catch-up even when you're really
interested in triaging a problem.)

Even if you had a perforce-supported way to get this done, such as a mildly
elaborate trigger to fire off the push (integ / resolve -at for each the
projects projects A, B, C, D, E and submit the 'newly made files'), this
would be the process question that would present itself.

I clearly have an opinion on it, yet it's important to stress that you have
the ability via a trigger. So, you can do it automagically if you choose.
(I'm not sure I would, based on the fussy-process questions above. I'd make
it easy for each project to pull from the main into its tools, at their
convenience. Depends on your engineering org's size -- fitting such
deliveries into their schedules, as a major push, might not be what you

Maybe you force-push tools each project, as it the project hits certain

  -Jeff Bowles

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

Jeff Bowles - jeff.a.bowles at gmail.com

More information about the perforce-user mailing list