Subversion 1.5 Merging Massacres

Recently, I had the opportunity to work with Subversion 1.5 on a medium sized project. Since there were more than 20 developers working on the project with some of them in a different country, there was no other way than to use feature branches extensively. We thought Subversion’s merge tracking would reduce typical merging errors by simplifying the process. But, well, we were wrong.

The sad truth is that few developers know exactly what their revision control system does behind their backs when merging branches. With Subversion prior to 1.5, things were pretty simple and there’s little magic involved. You have to be careful to state the correct revisions and if you don’t, you can still roll back your changes.

With 1.5, as long as everyone plays by the rules and sticks to the basic use cases, everything is fine. But if things go wrong (and they will), you’re really screwed. In a large team, there will always be someone who uses a buggy Subversion client, or someone who accidentally deletes merge properties (there’s often a high stress level before releases). And as soon as this has happened, merges may leave out revisions (or merge revisions twice) and you need in-depth knowledge to repair the damage. In some cases, even rolling back changes on trunk wasn’t enough if someone created a feature branch at the wrong time.

In a project consisting mostly of source files in a compiled language like Java or C#, obvious mistakes typically show up early. If you have lots of HTML, CSS, and XML configuration, or you’re working with an interpreted language, you don’t have this safety net. Your QA department (if you’re lucky enough to have one) will be the first to discover the problems.

So, if you’re a mostly happy Subversion 1.4 user and you’re considering migration to 1.5 or later for merge tracking, then my advice is: Don’t bother. Maybe recent versions fixed some of the problems, but I wouldn’t take chances. You don’t want to spend your nights fixing your source repository.

This entry was posted in tools and tagged , , . Bookmark the permalink.

5 Responses to Subversion 1.5 Merging Massacres

  1. panzi says:

    Hm, would this have been more easy using mercurial or git? After all, those VCSs are built around merging.

  2. mafr says:

    I can imagine their implementation of merge tracking is more mature and would have caused fewer problems from the technical side. However, we were on an extremely tight schedule, so we couldn’t switch to a VCS that most developers never had used before. In this situation, even switching to Subversion 1.5 was a big step.

    Apart from that, there’s still better tool support for Subversion and we needed tools for Windows, Linux, and Mac.

  3. Matt Doar says:

    This post would be more helpful if it included some specific details (“buggy client” – which one?). People deleted merge properties, really? Well, I guess a precommit hook could check for that. It just seems a bit of a broad brush statement to say “don’t bother upgrading from 1.4 to 1.5”.

  4. mafr says:

    We had a pre-commit hook in place to lock out clients that didn’t provide the “mergeinfo” capability. Unfortunately, we were forced to disable it because a widely deployed client (I think it was a slightly outdated version of the Subversive Eclipse plugin) didn’t send mergeinfo although it did create merge properties. After that, a couple of people merged using older clients and the damage was done. The automatic reintegration didn’t work reliably anymore. Some people got desparate and cleared merge properties manually.

    My point is that if you decide to switch to 1.5, you should be a lot more careful than we were. Make sure all your svn clients are compatible and educate your developers. In my opinion, the upgrade from 1.4 to 1.5 more trouble than it’s worth. Developing software on a tight schedule is hard enough, you can’t waste time struggling with your revision control system.

  5. cjlee112 says:

    I don’t want to sound smug, but these things are dead easy in git. I am busy branching, merging, rebasing all the live-long-day with all my fellow Pygr developers, and am happy as a clam every minute of it. I myself usually have 5 or 6 experimental branches going at any one moment, and so do most of the other people on our team, and we never need to give a moment’s thought to whether “we’ll be able to merge our branches cleanly”. Git works so well!

    — Chris

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s