Branching and merging in Subversion is worse than I thought

Posted at 07:00 on 06 September 2010

The other day, I was reading up about branching and merging in the Subversion book, when I came across this:

In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It’s not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again. For this reason, if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk.

In other words, while you can merge repeatedly from trunk into your branch, you can only merge once from your branch back into trunk! After that, your branch is effectively useless, and any attempt to merge either way will just screw everything up.

This is a shocking limitation. It drastically curtails the usefulness of branching and merging in Subversion.

I’d always known that branching and merging in Subversion was nowhere near as user-friendly as in Mercurial or Git, but I’d generally assumed that you could emulate Mercurial-like workflows with Subversion 1.5 or later if you really, really wanted to, by creating a mental model of your branches as a DAG, like what you see in the TortoiseHg repository explorer, and treating them accordingly. I’d also assumed that the only real difference between Subversion’s merge algorithms and Git/Mercurial merge algorithms was merely that Git/Hg gave fewer conflicts, e.g. by being able to track renames.

It turns out that I was wrong.

This rules out private branches, for starters. It also rules out dedicated branches for parallel development on your beta, UAT and live releases. It raises a serious question mark over Subversion’s ability to merge changes between two non-trunk branches. And it also raises serious question marks over the integrity of merges carried out by anyone without a thorough grasp of how svn merge actually works.

I know some seriously smart people who are scared of branching and merging in Subversion, and it seems that their caution is much more justified than I thought. Certainly, it seems that svn merge is best avoided unless you really know what you’re doing.

I view robust branching and merging as the number one non-negotiable must-have for any source control system these days. With limitations such as these, I am seriously starting to question whether Subversion is fit for purpose as a source control tool at all. All the more reason to switch to something else.