Trying Out Subversion

... that's the version control system, not anything political.

My first experience of file versioning was in college, where the main VMS system had it as a feature of the operating system. Older versions of a file would be preserved and could be retrieved fairly easily. Unfortunately, disk space was at a premium, so we would run the purge command fairly regularly.

Next came RCS, the granddaddy of open source version control systems. There were two commands: ci and co (check in and check out, respectively). It was file based and it was simple.

For a long time we used SCCS at work, because it was bundled with the commercial Unices of the day, Solaris in particular. sccs edit and sccs delget were the commands to use. Otherwise, it was essentially similar to RCS.

CVS was the next step up. Sure, you had to compile it yourself, but it was worth it. Two features were killers:

• access to remote repositories
• tags and branches

It helped that there was plentiful documentation, including the CVS book, and support in the popular IDEs, include Eclipise.

CVS has those killer features, but it is showing its age. The support for tags and branches is sometimes a kludge and sometimes worse. It's too easy to make a mistake when you try to merge code between branches. When you delete or rename a file, it's as if you are creating a new file from scratch. This is an important difference: Subversion versions not only file contents and file existence, but also directories, copies, and renames.

Subversion has been controversial. The somewhat notorious 2003 e-mail on its failings by Tom Lord gives one pause. Greg Hudson's reply helps to put it in context: if you are happy with Subversion's idea of snapshots of trees of files, it's a reasonable replacement for CVS.

More importantly, there's a Subversion book, the software reached (and passed version 1.0) and there's support in Eclipse.

I'm going to try it out for one of my projects here and see how it goes.