Really using Subversion

I have been using Subversion for more than three years. I use it every day. It is the version control system of choice within Oxford University Computing Services (OUCS). But until recently I hadn’t really used Subversion. Or, at least that’s one way of thinking about it.

It is worth a brief digression to consider why we use Subversion within OUCS. I’d like to say it is because we went through a thorough procurement process, arrived at the best possible solution for our needs, and then implemented the action consequent on that conclusion. That’s the ideal. But the dreaming spires of Oxford are just as bound by the contingencies of the real world as anyone else. Prior to switching to Subversion we used Perforce as our version control system. Perforce is an excellent solution – if you can afford the licence fees. I’m not certain of the sequence of events that took place (my role within OUCS doesn’t have me moving in those circles). The upshot was that suddenly we would have needed to pay about 100 thousand pounds if we were to continue using Perforce. Maybe other institutions manage their finances differently, but in Oxford it would take a miracle to change the budget for a sub-unit like Computing Services at short notice. And let’s be honest, 100 thousands pounds was just not going to happen. Not for something invisible like a version control system. So, we needed a solution, we needed it quickly, and, effectively, the solution was not permitted to have any impact on the overall budget.

Do you face these kinds of choices? They are not ideal. But in this case we were lucky. Just at that time a new open source version control system was coming on the scene. For many years CVS had been the standard version control system in the free and open source world. Subversion, an initiative from CollabNet, was being designed from the ground up as the next generation replacement for CVS. Subversion is also an open source project. That solved the cost-to-acquire issue. Its pace of development was substantial, and has continued to be so. And the community of users and developers around it was already large and growing. All that was left was to do some stress testing and then gradually roll it out, one project at a time.

OSS Watch was one of the first groups with OUCS that began using Subversion. Back in those days I had no familiarity with non-Windows operating systems. So I needed to interact with the Subversion repository via a Windows client. Fortunately there is an excellent one, whose development has followed pace with Subversion itself: TortoiseSVN. (TortoiseSVN is released under the GPL licence, whereas Subversion itself is released under an Apache/BSD style licence, even though they both come out of the same development house – a good example of the fact that choice of licence should be on a project by project basis.) TortoiseSVN installs as an extension to Windows Explorer. It takes only a moment or two to install it and barely any longer to learn how to use it (probably even faster if you already have a grasp of what version control systems are meant to be doing).

And since then I’ve used Subversion via a GUI client nearly every day.

But recently I began wondering how open source development projects use Subversion. My guess was that they use it differently than I have been using it. And I was correct.

At OUCS we have greatly simplified our interaction with Subversion. In part that was because we needed to bring along dozens and dozens of staff who were going to find, what I described above as blindingly simple, a challenge. So we went with a simplistic preview/publish distinction and left it at that. We didn’t even insist that publish would need to be a branch or tagset of preview. So there is not necessarily any trail of history between equivalent files in preview and publish. Again, a contingency necessitated by our install base. Probably everyone faces such challenges.

In order to learn how to really use Subversion for code development, I turned to the best source possible – the documentation written by the developers themselves. Version Control with Subversion is an online free publication that details nearly everything that you could possibly want to know about Subversion. I have learned about trunks, branches and tags. I have even discovered just how easy it is to use Subversion directly from a terminal window. It is all very straightforward and immensely logical.

I confess it has been a revelation for me.

In Producing Open Source Software, Karl Fogel claims that developers are unlikely to take your project seriously if it does not use version control with at least minimal competence.

I think he is right.