An Agile Perspective on Branching and Merging

it a breeze most of the time.

Case Study - Changing Business Requirement Forces Branching
One example was an organization producing a Java/HTML based web-service, hosted by themselves. They were a pure XP shop, and had been working with a single mainline for over 2 years, making fortnightly releases. Very few bugs had escaped through to live production, and the few that did could usually wait for the next release, less than 2 weeks away.

However, business requirements changed, and in this case it was functionality that the business decided to implement and get ready to go live, and yet was lacking the final signature from the client to allow it to be released. With just a mainline, these changes either had to be backed out or they held up the whole release - neither situation a very pleasant thought. This scenario was not just a one-off either - so they introduced a release line and started to "promote" code to it that was fully tested and authorized without affecting the implemented but not fully authorized changes. This worked very well for them.

Case Study - Branch on Conflict
In their paper presented at the BCS CMSG 2005 Conference, SCM in a Large-scale Agile Development , James Dyson and Paul Spalding describe a problem they encountered where functionality needed to be removed "at the last minute." Similar to the previous case study, "there were occasions where, towards the end of an external iteration, things had changed and the business either wanted to remove some completed functionality, or wanted to de-prioritize some incomplete functionality in favor of spending more time on some newly-important requirements." The tool they chose, CVS, did not support this partly because of the lack of atomic checkins. Other tools do support this more readily than perhaps they discovered at the time (which did start in 2002 when such tools were fewer on the ground).

A related problem was the desire to "branch on conflict." The idea being that in normal cases they wouldn't branch. However, if a user had a conflict due to ordinary parallel development, the tool should save the current state before the conflict merge since what is in the workspace this is a consistent working version (passes all unit tests). This is similar to the Private Checkpoint pattern mentioned in our previous article. In this instance, an automatic Private Branch would be better Private Checkpoint since the conflict needs to be recorded for posterity to help the removal of the functionality if the business wanted it.

This sort of functionality is not difficult to do in those tools supporting atomic change-sets and good branching with some fairly simple scripting if necessary as shown below.

Figure 5 - Branch on Conflict

Figure 5 shows the sequence of events for a single file (M n is the name/revision on the Mainline, F n on the Task branch). Of course behind the scenes the script would need to branch all the files in the change-set Fred was working on so as to have a consistent change-set in the Task branch. The naming of the Task branch could be created automatically using some simple heuristics, possibly including the date/time of the change or some similar identifier. While this might at first sight appear complicated it is not difficult to do and the results are the storing of the stable implemented function which would be very easy to remove cleanly if future business needs dictated.

Conclusion - Making Branching More Agile
As has been know to SCM practitioners for a long time, branching and merging are very capable tools