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.