Private Branching with P4Sandbox
The advent of distributed version control systems like
gitpointed out a need for better private branching tools in version control. P4Sandbox is Perforce's answer to that problem. Before I get into the details, it's worthwhile to take a look back at how the problem arose.
Mechanically making a branch, whether for release maintenance or just experimentation on a new feature, is actually pretty simple in Perforce and most other version control tools. In fact, it was probably too simple. Proliferation of branches could cause organizational and release management problems. Spaghetti branching caused a lot of headaches, and at the most basic level it meant that we weren't always sure if bug fixes and new features were being merged to the right places. That had a direct impact on the quality of the software.
Spaghetti Branching: I've Seen Worse
So the release managers wanted a cleaner branching model, and usually put some policies in place to make the branching model simpler and easier to manage.
Clean Branch Model
These are obviously competing goals. Developers want the freedom to experiment quickly, but there has to be some order in the chaos, or we won't be able to ship software.
gitwas the answer that favored the developers. You can do whatever you want in
git, but building the release management and organizational pieces on top of
gitcan be challenging. Systems like ClearCase UCM were the other extreme - a lot of process and policy.
I think Perforce has a great answer for both camps now. Streams provide a lightweight framework for release management and enterprise branching, while P4Sandbox provides the ability to be creative and make new branches privately. To each her own, as the saying goes: a strong central branching model for collaboration, and private branching for local work.
After that rather long introduction, how exactly does P4Sandbox let you do private branching? Its pretty darn simple. To start with, I've created a new sandbox pointing to the
mainbranch of a product called Jam. The sandbox has two streams set up initally:
Stream //streams/local development //streams/mirror 'local' Stream //streams/mirror mainline none 'mirror'
mirrorstream is the staging ground for pushes and pulls to and from the main server, while the
localstream is my initial private branch.
At this point I can work in the
localstream, periodically merging in changes from the main server, then pushing my completed work up when I'm ready. At some point I might want to make a second local branch to experiment on a new bug fix. I can do that by making a new stream called
p4 copy //streams/mirror/... //streams/test/...
P4Sandbox will make the new
teststream as part of running the
copycommand, and switch my workspace to use the new stream.
Switching to a different stream is very efficient. P4Sandbox updates my local workspace, only sending the files that actually differ. It also automatically shelves any work-in-progress when I switch to a new stream, so it is very easy to move back and forth between tasks:
p4 switch local Shelving files for change 23. edit //streams/test/depot/Jam/MAIN/src/Build.mpw#1 Change 23 files shelved. Client bruno_ws switched.
During this entire process, I can use the normal Perforce merging commands to merge changes between local streams. Before I send completed work up to the main server, I'd make sure there are no further changes there to merge down:
p4 merge -S //streams/local -r //streams/mirror - all revision(s) already integrated p4 copy -S //streams/local Client bruno_ws switched. //streams/mirror/depot/Jam/MAIN/src/command.c#1 - sync/integrate from //streams/local/depot/Jam/MAIN/src/command.c#2
Now P4Sandbox will copy my changes to the
mirrorstaging stream and from there up to the main server. When finished, it will switch my workspace back to the
localstream so I can continue working.
Using P4Sandbox for private branching is really that simple. If you're familiar with Perforce branching already, then using P4Sandbox will be a piece of cake.
The important point here is that these branches are my private playground. I can make as many branches as I want, try out new techniques, and experiment, without affecting anything on the central server. I choose when to pull in changes from the main server, and when to share my work.