[p4] [Newbie]: Mapping one depot to multiple locations in sameworkspace
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)!
- 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.
More information about the perforce-user