Steady on Subversion
My secret shame
In a world of distributed version control systems I’m ashamed to confess I still use Subversion. We use it at work, exclusively. I use it at home, by default. Worse still, in a small way, I help promote and perpetuate this antiquated version control system: if you want to mirror a Subversion repository or set up a Subversion pre-commit hook, you may well find some faded notes I wrote on these subjects.
Whisper the words. I still like Subversion.
What do I like most? The command to revert a change. Merge it backwards.
$ svn merge --change -666
Branches and tags are one and the same. For someone who grew up with CVS, that’s quite a relief. Anyone can grasp the versioned file tree model. No one wants their version control system to surprise them. My boss, who doesn’t get to program as much as he’d like, has discovered a shiny Subversion client — and he doesn’t even use Windows. The sales team, who do use Windows, can use Subversion to collaborate on their office documents. TortoiseSVN interfaces to the Word diff tool, a nice touch. And software developers can surely find stable Subversion plug-ins for whatever tools they use.
The Subversion documentation is solid and has been for some while. I’m surprised anyone ever arrives at my website seeking tips, but arrive they do, and in ever-increasing numbers.
Subversion does enough. The hard parts of my job are deciding what software to write, writing it, and working as a team. Version control should be frictionless, the easy bit. Which it is.
Of course Subversion has weak points. It should be faster (whee, see how git flies!) and merging can be irksome (improving on CVS wasn’t much of a target). But the biggest annoyance I’ve had with Subversion is caused by its ubiquity and its continuing upgrade trajectory. Somehow I’ve ended up accessing 1.4 and 1.5 format repositories on a machine which hosts 1.4, 1.5 and 1.6 clients in /usr/local/bin, /usr/bin and /opt/local/bin, not necessarily in that order. Silly me, I’m sorted now, I think, but I’d happily see Subversion go into maintenance mode. For managing change, give me stable software.
Do it the same, but better!
As mentioned at the start of this post, though, the world of version control has itself changed. Subversion represents evolution: by being a better CVS, it aimed to supplant its ancestor and become the VCS of choice for open source projects. CVS has indeed been supplanted, but true progress has come from the distributed version control revolution.
We’ve been talking about a single, central source tree which develops in discrete steps. Everyone has a local working copy of the files in this tree, which they keep up to date, routinely merging changes back to base. Check out, check in. It is an easy model to understand, but in practice there can be problems. What happens when you can’t access the tree? Or when it gets pulled in different directions? Or when you lose track of who merged what where when? Now consider the distributed version control world, where the model extends to multiple trees. Everyone copies the entire repository as needed. Clone, merge.
In this distributed world a project needn’t have a single, central repository1. What’s more, there is no single leading distributed version control system. As a result, open source projects are spoiled for choice.
The rise of the DVCS is a fascinating history, though one I’ve yet to directly engage with — unless you count the growing collection of DVCSes taking root on my hard disk (none of which shipped with my operating system). I like the feel of git. Python will migrate to mercurial. For now, I’m staying put.
Definitive commentary
Ben Collins-Sussman is one of the original designers and developers of Subversion, and co-author of Version Control with Subversion. His essays on the changing field of version control make fine reading. A couple of years ago he wrote:
Today, Subversion has now gone from “cool subversive product” to “the default safe choice” for both 80% and 20% audiences. The 80% companies who were once using crappy version control (or no version control at all) are now blogging to one another — web developers giving “hot tips” to each other about using version control (and Subversion in particular) to manage their web sites at their small web-development shops. What was once new and hot to 20% people has finally trickled down to everyday-tool status among the 80%.
The great irony here … is that Subversion was originally intended to subvert the open source world. It’s done that to a reasonable degree, but it’s proven far more subversive in the corporate world!
— Ben Collins-Sussman, Version Control and “the 80%”, October 2007
In April last year he followed up with:
[…] we think that [Subversion] will probably be the “final” centralized system that gets written in the open source world — it represents the end-of-the-line for this model of code collaboration.
It will continue to be used for many years, but specifically it will gain huge mindshare in the corporate world, while (eventually) losing mindshare to distributed systems in the open-source arena … Subversion isn’t anywhere near “fading away”. Quite the opposite: its adoption is still growing quadratically in the corporate world, with no sign of slowing down. This is happening independently of open source trailblazers losing interest in it. It may end up becoming a mainly “corporate” open source project (that is, all development funded by corporations that depend on it), but that’s a fine way for a piece of mature software to settle down.
— Ben Collins-Sussman, Subversion’s Future, April 2008
Long live Subversion
Ben Collins-Sussman backs up his essay with a graph showing the increasing numbers of Apache Subversion servers discoverable on the internet. His claims square with my personal experience. I’m a corporate Subversion user and I don’t see my employer switching version control systems any time soon (it’s my decision as much as anyone’s). What’s more, Subversion is used in most of the companies I know of, where it has supplanted both legacy and proprietary systems. As stated already, version control isn’t the hard part of my job, but should I ever need to change jobs, Subversion won’t stand in my way.
1: A project may well choose to nominate a single central repository as the “master” repository. The functionality offered by distributed version control systems is effectively a superset of that offered by centralised ones.
Articles