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

Robert Cowham robert at vizim.com
Tue Mar 31 11:12:25 PDT 2009

The idea of "master->slave" branches where there is a single master people
use, and multiple slave branches which are just copies, has been around for
many years in Perforce.

Jeff Bowles presented a simple example back in 1996 (now deleted as not a
good example of scripting - but the principle still holds)!


Implemented via:

- a config file which says which master slave relationships exist
- protections or trigger which prevent updates to the slave "copies"
- a daemon (or trigger) which automatically propagates any changes from
master to the various slaves (via same config file)

So a little automation, but works very well.


> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Philip Panyukov
> Sent: 31 March 2009 18:41
> To: Ivey, William
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] [Newbie]: Mapping one depot to multiple 
> locations in sameworkspace
> 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

More information about the perforce-user mailing list