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

Matt Janulewicz matt.janulewicz at lucasfilm.com
Tue Mar 31 11:30:09 PDT 2009

A scenario where the same code/library/etc. is branched to multiple 
projects and never changed always raises a red flag with me. I wonder 
why there is often a 'need' to do this instead of making a common area 
for the actual common code and having multiple projects refer to that.

I have seen very few, rare cases where it seemed like this was the only 
option (MS VisualStudio 2003 web projects come to mind) but there were 
always other alternatives.

As a 'CM guy' I try to provide 'one truth' to my users and can't recall 
any situation where branching a 'stable' library/tool to every project 
that uses it resulted in an easier path to development. Changes are 
eventually made to one copy of the tool, not properly propagated to the 
17 copies of it, then you basically have no way to baseline your code, 
you create a maintenance nightmare, etc., which could have been 
prevented with very small tweaks to the code or architecture. It's 
usually a case for refactoring.

In the case where multiple legitimate versions of a tool are needed for 
different projects, I've always found it easier to include them all in 
the common area and tweak client specs, rather than maintain multiple 
branches of the same thing.

If your tools are significantly large, it seems hard to justify spending 
the time to sync 3 or 4 copies of the same 100 megs of libraries if you 
work on multiple projects (multiplied by the number of developers you have.)

Maybe I'm not experienced enough (12 years in the SCM field) or have 
been lucky, but what are the legitimate arguments for maintaining 
multiple, identical code trees? So far I haven't come across a 
legitimate reason for it.


Philip Panyukov 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