[p4] Private Developer Branches - was Sandboxes without branching

sandy currier sandy at releng.com
Mon Sep 3 22:41:13 PDT 2007


(This is a delayed response to a previous email thread from last week -
Sandboxes without branching)

It sounds like you may be looking for a Private Developer Branch SCM pattern to
use within Perforce.  As another reply has already referenced, you can try
looking at http://www.releng.com/p5layer.html.  That package implements a
dynamically backed Private Developer Branch (PDB) pattern.

This is a SCM design pattern that is more commonly seen with Accurev or
ClearCase.  Basically, the pattern is to create private user branches off to
the side (in a separate depot in the p5 case) whether or not the file has
already been opened (it will not lose pending integration history).  The
branches are maximally sparse - only the files of interest are branched.

So, if your trees are 1,000's or 100,000's of files, but if your task only
involves five files, the package will automatically create and manage branches
for just those five files.  Note that PDBs, like other SCM design patterns, are
not applicable for all situations - they are not well suited for the creation
of shared development branch patterns for example.

In process space, one advantage of PDBs is that one is not necessarily bound by
the process rules of the backing branch (by default).  Thus, even if the
backing branch has high process, one can generally 'get-the-work-done' on a PDB
(checkpointing as you go) while at the same time dealing with the process side
of the house.  Other advantages include the general ability to shelve and
unshelve one's work (Microsoft's terminology), the ability to have one's
checkpointed Work-In-Progress reviewed or schlepped around various branches
with a minimal amount of merging (only the changed files are merged, not the
unchanged uninteresting ones), or move one's work to another backing branch,
etc.

Hope this helps.

-sandy

p.s. as also mentioned in this thread, this is different from using a local
perforce server to perform offline work (or to implement a DSCM type
solution) - that is a slightly different workflow.


> For the sake of argument, let's say that user branches cannot be
> created.  Users want to edit a group of files for some time in a sandbox
> with complete (though temporary) version history and then submit into
> Perforce.  How would one then create such a sandbox?
> 
> Several recent threads have mentioned various shelving methods (p4tar,
> scripts, etc.) and a third-party product, CodePickle.  These solutions
> all seem to involve a save/rollback/resume model that does not include
> support for versioning.  One solution I'm investigating involves using
> both a local and remote Perforce server with separate workspaces mapped
> to the same root.  Obviously this would require user diligence to keep
> each up to date but in theory this looks like it should work.
> 
> Has anyone else worked on a similar system or have any ideas how best to
> accomplish this?
> 
> Thanks,
> Mark


More information about the perforce-user mailing list