The team behind the open source SCM (Software Configuration Management) tool Subversion released version 1.50 last month. Karl Fogel, president of the Subversion Corporation, says:
Measuring by new features alone, Subversion 1.5 is our biggest release since version 1.0 became available in February 2004.
I am a contented Subversion user, so took a look at the changes. Top of the list is “merge tracking”, though it is described as “foundational” which means that although the basic support is there, there is performance and feature work which remains to be done. From the user’s perspective, the difference is that branching and merging is just easier than before, as explained by Ben Sussman:
Notice how I never had to type a single revision number in my example: Subversion 1.5 knows when the branch was created, which changes need to be synced from branch to trunk, and which changes need to be merged back into the trunk when I’m done. It’s all magic now. This is how it should have been in the first place.
Other changes include sparse checkouts (when you only want to grab a small part of a repository), and changelists, a client feature which lets you tag a set of files under a changelist name and work on them as a group. There are also improvements aimed at making Subversion better suited to large-scale deployments using multiple servers. Subversion is still a centralized rather than a distributed SCM system, but 1.5 is better suited for use in a distributed manner. No doubt the Subversion team is aware of the increasing interest in Git, a distributed system. There are also numerous bug-fixes and performance tweaks. The changes are described here.
I want to move to Subversion 1.5 but it is not that easy. Compatibility is good, in that older clients work with 1.5 servers and vice versa, the main proviso being that you cannot mix several versions of the Subversion client with the same working copy. That is not likely to be a problem for most users.
The difficulty I encountered is that mainstream Linux distributions still have older versions of Subversion in their stable repositories. Ubuntu, for example, has version 1.4.4. My most-used Subversion repositories are on a Debian server, which also has an old version. I don’t want to switch the server to sid, Debian’s development distribution, and mixing packages is often problematic. I could do a manual installation I guess; but instead I will be patient.
I did install 1.50 on Windows, for an intranet repository. I used the Collabnet download. All I needed to do was to inform the installer of the location of my existing repository, and then copy a few lines from the old Apache 2.0 configuration file to the new Apache 2.2 configuration file. Everything works fine. I also updated TortoiseSVN on the Windows clients.
One of the advantages of Subversion (or any SCM) repositories over synched folders like those in Microsoft’s Live Mesh or Apple’s MobileMe (as I understand it) is that you get version history. I regard this as a key feature. The problem with synchronization is that you might overwrite a good copy with a bad one. It is easy to do; it might be caused by user error, or a bug in your word processor, or a failing hard drive. Automatic synch (un)helpfully replicates the bad copy all over. Versioning means you can just rollback to the good one.
Changelists are a nice new (client) feature. TortoiseSVN has the “ignore-on-commit” changelist that make it easier to not inadvertently check in changes to things like config files.