How to save Subversion (SVN)

In the last few months, Subversion has been heavily criticized by the software development community, with reason. While Subversion was a great replacement to the old versioning systems like CVS and Visual Source Safe, the newer alternatives are really starting to demonstrate how bad Subversion really is.

Merging

This is probably the single most problematic issue with Subversion. Merging often causes headaches, errors and wastes a lot of precious time that could’ve been spent on development. Merging is so bad that many teams avoid branching so that they don’t have to deal with the merge later on. Mercurial (hg) and Git have both improved this aspect tremendously and I’m pretty sure its the reason why most people are moving away from Subversion.

The reason why Subversion has trouble with merging has to do with the way it stores the version history.

Subversion likes to think about revisions. A revision is what the entire file system looked like at some particular point in time.

In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision.

Source: HgInit: Subversion Re-education (an excellent tutorial and guide to Mercurial or other distributed version control systems)

So Subversion compares whole files when merging while Mercurial (or Git) compares each change set individually. Conflicts occur far less frequently when dealing with changesets.

Improving SVN

Use changesets

As I said earlier, the biggest difference between Subversion and Mercurial/Git is the way they each deal with modifications to files. If Subversion started using changesets instead of revisions, a lot of the headaches and problems would disappear.

Local commits

Another advantage of Mercurial and Git over Subversion is their distributed nature. With Mercurial and Git, you can commit changes locally on your drive whenever you want (while you’re offline too) and commit all those local changes to a central repository at the time of your choosing. This improves commit logs since the developers don’t have to worry about breaking anything until they actually commit to the central repository (or push their changes if we use the distributed version control system terminology). You can even have multiple intermediate repositories between the developers and the central repository. For example, all developers could commit to a team lead repository which would review every changes and then commit the reviewed modifications to the central repository.

So, to improve Subversion, I don’t think the multi-stage distributed system is necessary. The real value is in local commits, the rest can be easily emulated by using a simple branching process.

Subversion’s future

Unless Subversion works on these two issues, I don’t think Subversion stands a chance against the newcomers. Slowly but surely, teams will migrate to alternative version control systems because they make branching fun again.

Bonus: Move all the repository information at the root

This one is not as bad as the others, it’s just a regular annoyance that could be improved. Instead of having Subversion meta-data in every single versioned folder, Subversion should keep all the info in a single meta-data folder at the root of the checked out repository.