Branchaholic

So, what are branches good for?

According to Subversion documentation, just for experiments, project splitting, and some other uncommon and weird things. And if you come from the opensource world, you will most likely agree on that... I will try to change your mind.

What are we using branching for? We use a branching pattern named branch-per-task. I started using it long ago, but I first read about it on Steve Berczuk's great book on patterns.

What branch-per-task means? Simply put: every code change we make on our system is related to a task, and every task has an associated branch. Now you think "but... this is a huge amount of branches!!". Yes, you're right! And then I ask: "ok, and what is the problem?". If you think on branches as something heavy, slow or uneasy... then you have never tried Plastic... :-P

We have been using Plastic for months, having a branch for each task. So, guess how many branches do we have?
The image shows our GUI tool listing the branches. We currently have about 900 branches, most of them already integrated in releases, some other just kept as discarded tasks. So, at any moment in time we just can go and ask the tool to show us what we did exactly on a certain task. And on each task we have all the changes done to every item involved... being able to exactly now how a certain feature or bug fix was implemented.

The screenshot shows the contents of a given branch, implementing a task closed long ago. Full branch isolation is very helpful to keep track of what was really done, showing you just what was modified on the branch/task pair. Compared to Subversion, or Perforce, which both duplicate all the metadata on each branch (a soft copy, but a copy anyway), Plastic branch management just puts on the new branch what really has been changed. This way branch content really means what has been modified on a branch.

Branches allow us to really have isolated changes. You can achieve something similar through changesets (which Plastic supports too), but branching adds some features. Ok, let's explain it: you have a certain version (baseline) of your product, let's say compiled and somehow approved last Friday. Then you need to do a couple of changes (yes, in a real scenario you will have to make ten or twenty a week, at least, but I will talk about just two for the sake of clarity). Change one is fixing a problem in your database layer, something related to transactions, something with some level of risk. Change two is a bit simpler, just adding some format to a given form.

Both changes have been introduced in your preferred task control system, they have a number, so when you talk about them everybody knows what you are talking about. And both tasks should modify a well-known, fully tested baseline.

Then developer 1 takes the first task, named task0830, to deal with the change in the database layer. It is a difficult modification, and it will take a bit more than one day.

At the same time developer 2 starts task0831 and rearranges a data entry form. The task is easy, but it will take one day to finish it.

First thing programmers benefit about branch-per-task is that they can commit as much as they want to the SCM. In other words, they can do as many intermediate checkins as they need. With the widely used model of code out / code in, normally implemented with Subversion and many other free version control systems, you only make a check in (or commit, depending on the specific tool) when everything is working, and you have passed all the tests. So, in the meantime, changes are just on your disk, and the system doesn't know about them. You can't check in when you have made a certain important modification to a file, just to be able to "roll it back" afterwards... But with branch-per-task you can check in at any time, so first you know your code is on the server, and you always have a "safety net" behind you.

If your team is using an agile methodology, or at least releasing often (even internal releases should be done at least once a week), you can reach the milestone and need to have something stable. Then you look at the two tasks you have developed during the week. The task0831 (form rearranging) will be most likely finished and correctly implemented, it was not very difficult. But imagine that you are not completely sure about task0830. It has just been finished but it has a big impact on your application, and you have even discovered a bug in the last moment... With the code out / code in model the code is already in the mainline... What can you do? With branch-per-task you are not in such a problem. You would decide whether you want to integrate it or not... More control, better results... and you wouldn't be in such a hurry...

To conclude, it is very important to highlight that the way a team work shouldn't be constrained by tool limitations, but instead powered by its capabilities.