Subverting the dominant paradigm

For our development services tax this week, Squirrel asked me to look into using a tool called Subversion. Subversion is a version control system that was written to correct various issues with CVS. We are interested in it for a couple of reasons (and I’m probably missing some here):

  • Better performance in some cases. For example, running cvs update in DevTools took forever, and often ran out of memory.
  • Keeps track of whole directory trees. For example, in cvs, if you delete a directory, you loose track of the history of it. Same if you move a file. SVN keeps track of the whole tree.

Things what I found while playing with the new toy

* Ubuntu roolz/SuSE droolz

SuSE may be a great distribution. But all our local SuSE machines run SuSE 8, which is something like four years old. And while YaST is nice, as far as I can tell, it only installs things off the CD. And even if it didn’t, no one seems to make binaries for SuSE. Or if they do, only the latest version or so. And compiling the source is such a pain…

On the other hand, installing on Ubuntu is a one-liner

sudo apt-get install subversion

Doesn’t get any easier.

As an aside, I always forget you can’t just type “su” in Ubuntu. You have to type “sudo su”. Which I guess is saying “as the root user, switch to the root user”. I like recursion as much as the next nerd, but that seems a bit excesive. Turtles all the way down.

* Decisions, decisions…

When making a new subversion repository, you are faced by several decisions. What kind of file system? How do you want to organize your projects? The nifty free book (Version Control with Subversion) lays out all the options and the pros and cons in a surprisingly erudite way. But you still have to make up your mind. For this experiment, I luckily had to make fewer choices, as I was only really dealing with one project (devtools). And the default file system (that actually uses files as opposed to a database) seems like a good idea for us.

* Converting the masses

There are a variety of nifty tools around svn. One of them is cvs2svn – a tool to convert existing cvs repositories to svn ones. This way, you can keep your change history. It is *slow*, and if you do something stupid (say, not run it as root when you are trying to write to a folder that requires root), it doesn’t fail until half an hour later. But other than that, it is pretty straight forward. One thing is that it automatically sets up your repository to have folders like “trunk”, “branches”, and “tags”. This is fine, but is a little different that cvs and you need to specify the right folder when you are checking out (see the wiki for an example).

* Results

All in all, it seems to work pretty well. I have used both the command line version and the Eclipse plugin, and they work basically how I would expect. Checking out devtools still takes a long time, but updating took only about 4 minutes (as opposed to half an hour to never for cvs). Checking in my little change to devtools took longer than I would have expected. But since svn versions everything on checkins, this isn’t too surprising. (Also, I was checking in via Eclipse, and sometimes it just likes to take time to do random things…)

I haven’t had a chance to play much more yet, but so far it feels like cvs. Feel free to follow the instructions on the (new) wiki to check out devtools to see for yourself!

2 thoughts on “Subverting the dominant paradigm”

  1. Personally, I’d prefer some sort of distributed revision control system, such as git, rather than a centralised one. As I recall, SVN isn’t too hot on merging either.

  2. As an aside, I always forget you can’t just type “su” in Ubuntu.

    You can if you set a root password. “sudo passwd”. Although what Ubuntu is trying to get you to do is to not use interactive root shells at all, and just prepend each individual command with “sudo”.

Leave a Reply

Your email address will not be published. Required fields are marked *