Home | Subversion Branch/Merge Strategies

Subversion Branch/Merge Strategies

Posted on Thursday, April 29th, 2010 | Filed under build management, development, subversion

Subversion is many things, but it’s not all things to all people. The project set out to create a better CVS, and that is largely what Subversion has been so far.

As a result of design decisions made early on, and a firm commitment to backwards compatibility, the project – at least until a 2.0 release – is locked in to its limitations. Merging, and more specifically merge tracking, has been a huge pain in the backside for large numbers of users.

The 1.5 release was mostly a lateral move from the svnmerge.py project, and subsequent releases did little more than patch a few of the more glaring holes in the original implementation, although conflict handling has seen dramatic improvements.

So how do we play into Subversion’s strengths without playing into its weaknesses? My answer to that is 4-fold:

1) Merge strategy

It may seem backwards to talk about this first rather than branching, but merging is way more complicated than branching, and so the peculiarities and limitations of merging in SVN may very well dictate you branch strategy, so I feel it’s important to understand the parameters of your options in this area, make the appropriate choices, and work backwards from there.

Merge tracking in SVN, although much improved over past releases, is still very much a work in progress. Your desired approach relies heavily on SVN’s ability to keep track of cherry-picked merges. To keep from hitting SVN’s current limitations, you’ll want to keep your merges very straight-forward, and be VERY careful to understand exactly what you’re doing when deviating from the model I’m outlining. SVN is very flexible and will let you get into all kinds of situations you’re not going to want to be in without adult supervision. The smart thing to do is to constantly ask yourself “I could do it this way, but should I?”

For example: you can merge files individually, but SVN is built around atomic revisions that generally contain changes to multiple files. SVN’s merge tracking feature attempts to keep track of partial merges of revisions, but is imperfect in this regard, so to avoid losing track of what has and hasn’t been merged, you should:

a) educate developers to not commit changes related to multiple issues at once
b) only ever merge entire revisions. I can’t stress this enough: never merge partial revisions.
c) if issues are or do happen to become legitimately intertwined, track them accordingly and not allow them to be merged/built/released independently.

2) Branch strategy

Now that we’ve established the parameters for how to keep merges manageable, the rest is fairly straight-forward in that it’s mostly dictated by this merge strategy.

You create a branch for a limited set of changes (project, set of bugs/enhancements, whatever the case may be). This in and of itself is smart. The concern is obviously that “what if I don’t want to merge/release/build everything on the branch, but rather a subset of these changes?”. The answer to that is – as is often the case – “it depends.”

You can either:

a) create a temporary integration branch (based on trunk), merge the changes you do want to it from the original branch, resolve any integration issues, and merge changes back to your trunk the same way you would otherwise. Scrap the integration branch (archive or remove) when it’s served its purpose. Branches are version-controlled in SVN, so you can always go back and restore one if need be.
b) selectively merge revisions from your branch back to trunk and resolve any integration issues on trunk.
c) merge trunk changes to your branch, resolve integration issues on the branch, and reintegrate your branch with trunk.

Following this model, you are never more than 1 step removed from trunk (i.e. you’re either on a trunk or on a branch, and a branch is always created from trunk), and changes never get merged more than twice (i.e. either from trunk to branch, from branch to trunk, or from branch to integration branch to trunk).

Depending on the scenario (changes in question, whether the merge is partial or complete) you *should* be going in one of these three directions. The important thing to remember, is that whenever you merge trunk changes into the branch, you should ALWAYS reintegrate that branch in its entirety. Of course, once you understand the rule, you can break the rule, but I wouldn’t go down that road unless I had an expert at SVN/SCM to manage the heavy lifting it will almost certainly involve, either immediately or eventually.

3) Hire an expert

Most companies still look at build/SCM work as something to volunteer a junior developer for. Few decisions will get you into trouble faster, or limit the effectiveness of the position more, than going this route. Build/configuration/release management is a skill set and I would even argue an art form all on its own. I cannot stress enough the value the right resource in that chair will bring to the table. The time and money saved, not having to deal with the immediate and ripple effects of issues that shouldn’t or don’t need to be, can save a project, or even a business.

4) Tools

Possibly the most important tool in all of this is what you use to keep track of all the information involved in doing the above and not miss something along the way. You’ll want to be using a tool that can

a) keep track of your issues (should be obvious, right?)
b) keep track of the relationships between your issues and use these relationships to automate notifications to developers when upstream issues change, possibly affecting downstream dependent issues (this eliminates the bulk of tools out there)
c) relate SVN revisions to issues
d) provide top-to-bottom traceability across all of the above

Comments

• About

  DGB is the brain child of me, Rob van Oostrum. I am a 14-year industry veteran. Today, I focus primarily on Build Engineering, Release Management and SCM, but I am known to dabble in the occasional Java/J2EE development project.

• Links

  • Rob on LinkedIn
  • Rob on Twitter

• Search

• Admin

  • Log in
  • Wordpress
  • XHTML