Private Brancher

Originally published in Develop issue 70, March 2007. Reproduced here with kind permission of Michael French.

With development today being more and more complex, the need to branch code and data is essential. Fortunately SCM tools are much better than they once were. Rather than getting into a debate about which to use, I’ll talk about Perforce in particular, as it’s fast becoming the de facto standard.

Here’s a quick recap on how to branch and merge. I always recommend using a “branch” spec; in the long run it’ll make things much easier. First, name the branch. For an easy life, I suggest making its direction obvious.

p4 branch main_to_dev

Now perform the branch. You can do this anytime you want to ‘update’ to the latest mainline versions:

p4 sync
p4 integ –t –b main_to_dev
p4 resolve –as

“–as” specifies a “safe merge”, one where only trivial changes are automatically merged. You’ll see in some documentation to use “–am”, a full blown automatic merge. I strongly recommend you never do this – I’ve seen too much lost code as a result. You may need to use the “–f” flag to force Perforce to resolve previously resolved files.

When it’s time to reintegrate from the branch to the mainline do the same, but with the reverse notation:

p4 integ –r –t –b main_to_dev

Of course, after resolving you really should test your changes ensuring they work before submitting. The bad news is that in that time someone else could check-in new code breaking yours, and with builds taking so much longer today (even with tools like Incredibuild) it’s quite likely.

One option is to consider locking the database to all check-ins except yours; immediately after the integrate, consider running:

p4 lock //depot/main/…

It’s pretty easy to wrap these steps up in some scripts, and there are Perforce APIs for most popular languages. Miki Tebeka has already written some that help the process and integrate with P4Win. Definitely worth checking out.

One significant problem with branching like this is that if you’re not careful it’s very easy to lose work. This can happen if the branch is shared, and the developer is not able to check-in work-in-progress. 

A private branch is an attempt to rectify this situation. It’s one where you can happily work and check-in changes worry-free. Accurev supports this practice with workspaces where you “keep” private changes, and “promote” public changes.

For Perforce, the steps above work just as well for private branches. The main issue is that you could be dealing with many more steps, especially if you’re working in a project sub-branch. Not particularly simple and one area where Perforce starts to buckle.

One solution might be p5layer from Release Engineering. It’s currently in beta, suffers from a few bugs and really isn’t production ready, but it does show a lot of promise. It attempts to mimic Accurev, down to the same terminology (keep, promote, update). So if you’ve moved from Accurev to Perforce, and miss “keep” you’ll be very comfortable.

It has some very nifty features; supporting offline working (by temporarily using a local perforce depot), “re-parenting” your work from one branch to another and branching work-in-progress . All these steps are usually very tricky with Perforce.

The other great thing is that rather than branch the entire workload, it only branches the data you’re actually working on. It works by using a “spec” and a private depot, tracking and making changes to client-specs. 

If you run a p5keep, look at your client-spec to see how it’s changed and get an understanding of how it works.

p5layer needs a bit of work, but what I like is that it works in conjunction with your existing structure, and doesn’t force a particular style of working on you. This could be an excellent addition to your Perforce toolkit, especially if there was a GUI.