Donnie’s Blog

Last week I covered version control systems in one of my classes, and of course I covered CVS and Subversion. That part wasn’t so difficult; it’s pretty easy to present the facts and the details and give the students the whole picture. (Well, as much as can be covered in a single class…) The challenge came about when I had to write up the lab assignment for the week. Should I make them use CVS or Subversion? Hmm!

Don’t worry - I really wanted to get the students to use Subversion, since these particular students already know they will be using it over the summer on a project. But, unfortunately, circumstances forced my hand on this one - the CS cluster didn’t have svnadmin installed, so the point was moot. So, I wrote up instructions on how to use CVS for the assignment, but gave students the option to use Subversion if they had their own machine to install and run it on.

Talking to the CS sysadmins uncovered a really interesting question: What happens to your repository when Subversion gets upgraded? The answer to that is pretty simple; you have to migrate your repository to the new version of Subversion, using the svnadmin dump and svnadmin load commands:

1. You use svnadmin dump with the old version of Subversion, to create a backup of your repository.
2. Then you upgrade Subversion.
3. Finally, you use svnadmin load with the new version, to restore your repository.

Simple, right? Well, as long as your repository isn’t too large; the default output of svnadmin dump contains the full contents (not the deltas) of every version of every file you checked into your repository, for the range of versions you decide to dump.

So, this is one aspect of Subversion where its youth is clearly evident. This isn’t an ideal procedure to go through when you upgrade your version control tools, and you would like to do this kind of thing as rarely as possible. It’s the kind of thing you can schedule to happen between product cycles, but if there’s a glaring issue in the current version that has to be patched, you’re just going to have to bite the bullet and take a day to upgrade the Subversion repository.

This also seems like a bit of a gap in the toolset for Subversion, one that I think would be fun to play around with and perhaps cook something up over the summer. Subversion needs some sort of migration tool that takes care of this kind of thing for you automatically. Why? Well, think about what happens on a computing cluster, and different users have their own code repositories that they use with varying frequency. The poor sysadmins have to manage software upgrades and patches, but now they have to worry about breaking people’s Subversion repositories too! But a “migrate” tool would make this pain go away, because repository migration would no longer require a “preparation” step before the Subversion tools are upgraded. Rather, users could gently be informed that their repository is out of date, and “By the way, this helpful tool will take care of that for you right now, if you like!”

So, I might start poking around on that one. It could be an interesting summer project to tinker with, along with all the other ones I already have on my plate. Something like that would really make it more feasible to provide Subversion on a multi-user computing cluster like we have here.

This entry was posted on Monday, May 15th, 2006 at 11:23 am and is filed under Caltech, Hacking. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.