The p5layer product attempts to implement Private Developer Branches (PDB's) on top of
Perforce. It is currently in beta, but seems to work well enough under load.
Background
For most enterprises, there are only 3 or 4 basic SCM Branching Patterns that
are required for effective SCM branching implementations. One of them
happens to be the Private Developer Branch (PDB). As a side note, the
other SCM branch patterns - for product based enterprises with monthly to
yearly release cycles - tend to be the Release Branch, the Task Branch, and the
3rdparty Branch. For website/IT enterprises with shorter release cycles
or with only a single active release, the Promotion Branch pattern is usually
more effective. See The SCM Pattern Book.
Interestingly, the Private Developer Branch pattern is usually most
efficiently implemented via dynamically backed branches. Dynamically
backed branches are SCM branches where only the actively being-worked-on files
are branched. Files are only branched when they are actively
being edited and not before - all other files are not branched.
Statically backed branching is the implementation where all the files are
branched at once before any modifications occur. Statically backed
branching will branch even those files that are never modified.
Some SCM tools effectively only offer dynamically backed branching, others
only offer statically backed branching, and a few offer both. Note that
just offering one type or another or both is not a compelling reason by itself
to select or discard a particular SCM tool - things are more complicated than
that.
However, with regards to PDB's, it is critical that the implementation,
whether it is out-of-the-box from the vendor or added on later, support a high
degree of usability as well as capability. This is due in part to the
fact that PDB's are part of the Developer Debug Cycle, one of the most
important (expensive - $$$) workflows of a sofware enterprise. Why? Because there
are many developers who at least in theory are spending a significant amount of
their time in this workflow.
Perforce currently only offers statically backed branching. With
Perforce, it may not be apparent how to implement the PDB SCM pattern with only
statically backed branches. The nature of statically backed branching
requires branching inactive files and dealing with the resulting merge
requirements. It also will decrease the usability of the existing
capability of inspecting the system for Work-In-Progress (WIP) files and status
- a loss of visability into parallel development. (Effective
implementations of SCM patterns require a high degree of usability and a
minimized set of negative artifacts.) With Perforce, PDB's will diminish
the usefulness of such out-of-the-box commands as 'p4 opened' and 'p4 edit'
since parallel work will be occurring in different branches instead of on one
shared development branch.
Those who are familiar with other tools or with SCM patterns in general know
how useful, in fact how necessary, PDB's can be. PDB's are also the SCM
pattern behind the concept of shelving
introduced by Microsoft's Visual Studio
Team System. The term shelving has also spread to subversion.
However, unlike subversion and other similar solutions, p5layer will get
all the merging correct automatically without manual intervention due to
Perforce's underlying merge capabilities and various algorithms within p5.
So, the P5 Layer is a set of perl scripts that implement Private Developer
Branches on top of the Perforce p4 CLI while attempting to provide the desired
usability and capability. The basic concept is to use a depot called
//private to hold all private developer branches. When a file is
privatized/kept, it is branched into this depot from the backing branch.
Thus, the privately branched files appear both in this depot AND are explicitly
listed in the clientspec as explicit/unique View: mappings. The
branching can occur pre or post p4 add, edit, integ, and delete commands - in
other words, the branching is basically pre-submit branching, not pre-open
branching. The user can decide after the work has been started as to
whether a private branch is needed or not.
For visualization, the open-source product p4db
by Fredric Fredricson has been somewhat highly customized so to be able to
display a user's WIP as well as branch and depot based WIP. This allows
users to easily and directly see merge overlaps between users.
There is a short tools.xml file within the deployment for importing into
P4V.
The basic operations currently support are:
| ACTION | COMMAND | EXPLANATION |
| keep | p5keep | Will submit opened files onto the default
private developer branch. Will handle files not yet added to Perforce as
well as files currently opened for add, edit, delete, and integ. Another
synonym for the keep operation is privatize. Privatized files are
also known as Work-In-Progress files, or WIP files. p5keep will
shelve current work, creating a shelf/WIP.
|
| promote | p5promote | Will remove the privatized files
(Work-In-Progress files) from the clientspec and integrate the files back into
the backing branch. Will nominally resolve the files.
|
| update | p5update | Will perform a p4 sync operation as
well as a p4 integ operation on all the privatized (WIP) files. Will
nominally leave the files unresolved.
|
| purge | p5purge | Will simply remove the (specified) WIP
files from the clientspec and sync the files to the backing branch.
|
| unpurge | p5unpurge | Will undo the affects of a p5purge -
placing the files back on the private branch (and into the WIP set).
p5unpurge can also be used to reset a clientspec to some previous value as well
as copy some other WIP into the current clientspec.
|
| wip | p5wip | Will perform various queries on the WIP files
of the current and other clientspecs. Will nominally print the current
WIP set. Some people refer to the set of WIP files as the 'default group'.
|
| reparent | p5reparent | Will reparent the WIP from one
backing branch to another. Note that since the p5layer has a high degree
of time safeness, reparent can be used to promote WIP to another branch without
loosing the current context. In other words, p5keep will create a
shelf (some WIP), p5reparent can move the shelf to another branch,
and p5unpurge can be used to return the client to the original state.
|
The P5 Layer can be downloaded here. Some installation configuration
will probably be required - there is a README.txt file contained within the
distribution.
Known issues:
- Needs to be re-written so to use perl hashes and objects - this is slowly
underway.
- On Windows, anti-virus checkers can lock files on the fly underneath
p5keep, which will cause p5keep to fail with file permission errors.
- Need to make a release of the customized P4DB available.
- Really need to document some of this stuff...
