Branches are hard

By Andrew Smith

Branches always freaked me out. From the day when I read the subversion manual I knew they are hard to deal with and the benifits are dubious.

If you ever had to deal with maintaining a fork, or a project that was forked – the technical challenges are exactly the same.

I imagine it’s reasonably easy to deal with if your commits to the version control system are atomic (e.g. one-liners to fix a bug). In that case you can just make a list of revisions with changes from one branch that you want in the other, and write a script to automate the merging for you. Do this for both branches and you’re fine. But life is not that simple.

There are two rules-of-thumb with version control that are relevant to this post:

  1. Only commit working code.
  2. One commit – one bugfix, or one feature.

The problem is these two are sometimes in conflict. For example: I change 5 files to add a feature and while doing that I run into a bug that’s in my way, I have to fix that bug or else my patch won’t do what it’s supposed to. So I end up with a patch that adds a feature and fixes a bug.

Yes, I could in theory somehow manage to not include the bugfix in my feature patch, but realistically that’s not doable most of the time – it’s just too much work.

Now I need to have a second branch for one of my projects, but I’m afraid to do it. I don’t have the time to go through svn logs, read all the patches, and merge the changes, sometimes manually. So the less profitable branch would end up out of date pretty soon. Which would be a shame, cause I’m rather fond of it.

Someone ought to extend subversion to be able to add flags to patches. So in my example above I could mark the bugfix lines as ‘BUGFIXP1′ and later tell subversion to give me all the patches marked so since some date in the past. Of course a change to a diff viewer would also be needed, so I can do the marking when I’m ready to commit.

I’ll put it on my list of interesting projects to work on but I don’t see the day when I’m going to have time to implement it. Oh well, maybe I’m just overly pessimistic about this.

2 Responses to “Branches are hard”

  1. Karl Fogel Says:

    Actually, what’s so hard about fixing the unexpectedly-encountered bug separately? I do this all the time. One way is to keep a second working copy around that’s just for those bugfixes. I commit it there, then update the tree I’m really working on.
    Another way is:

    $ svn diff > saved-work
    $ svn revert -R
    $ [edit to fix bug]
    $ svn ci -m “Fix bug.”
    $ patch -p0 Quilt might be one of them). Also, there are other version control systems with better out-of-the-box support for this scenario (see Mercurial and Git), although I think it’s pretty easy with Subversion too.

    As for the other problem you described: branch management will get significantly easier in Subversion 1.5, which will ship with a merge-tracking feature. I’ve been using it in development, and even as an incomplete feature it’s made my life easier already.

  2. Andrew Smith Says:

    A working copy just for bugfixes – that’s not a bad idea, thanks for pointing it out.

    What’s the merge tracking feature you’re talking about? Can I read about it somewhere?

Leave a Reply