From Visual SourceSafe to Subversion

 05 April 2009  software-engineering

A few years ago, we (at the company I work for) decided to move away from Microsoft Visual SourceSafe (VSS) to Subversion. The tool vss2svn is available to ease the conversion, and with Subversion and all the tools open source, it was a low-cost route into a modern, reliable and well-supported version control system.

Before getting started, read up on Subversion. It does some things differently to VSS - well, to be more accurate, VSS does things differently to just about all other version control systems - so it’s well to understand what the new system is like. Take a look at my previous article and follow the links to understand how things like VSS’ branching is peculiar to itself, for example. Also have a good read of Eric Sink’s Source Control HOWTO for a full primer on mainstream version control systems.

To learn about Subversion, your first start is the official book, Version Control with Subversion, available both online and in print. Also have a look at Pragmatic Version Control with Subversion, from the Pragmatic Programmer’s bookshelf.

Of course, nothing is better than actually trying the software out yourself. Subversion can be tried in a single-user configuration, a local repository accessed over the filesystem, which makes it very easy to try for yourself. Create a repository, add some stuff to it and experiment with checking in, making copies and branches and doing merges. Try out TortoiseSVN for an excellent front-end onto Subversion.

In reality, you will need to run Subversion in a server configuration. Subversion has a module for Apache and also a standalone server. We chose the Apache option, but this does require confidence with command lines and text file configurations (my previous life working with Unix and Linux helped!) However, since we set up Subversion, products such as the free VisualSVN Server make setting up and administering Subversion servers achievable entirely through a good UI.

But what about everything you currently have in Visual SourceSafe? Fortunately, vss2svn will convert a VSS repository into a format that can be loaded into Subversion, so you can keep all your work, complete with history, when you start with Subversion. Some VSS concepts don’t match perfectly onto Subversion (for example, VSS doesn’t have atomic commits) so it’s not a perfect conversion, but in practice it works well.

vss2svn is written in Perl. I had difficulties getting the prepared vss2svn.exe working on windows, so I decided to run the Perl scripts on Linux instead. The conversion takes hours, so I let it run overnight. The output of this is a Subversion dumpfile. Create a new repository in Subversion, and then run svnadmin load to load the dumpfile into the empty repository. (I decided to use the -parent-dir option to svnadmin to place the VSS repository into a subdirectory of the new repository - this allowed us to, over time, rearrange the repository structure from fresh, while keeping all the historic VSS projects as they were.)

We made this conversion over two years ago, and despite some nervousness about the maturity of the tool, not to mention the rather large number of things in the ‘orphaned’ folder, it has worked perfectly. We have not seen a single issue with our converted repository. I am very happy with our much improved source control system!

Once you’re confident of your new Subversion system, you can experiment with adding more tools to it. ViewVC adds a web-based repository browser. Hooks allow you to write scripts that fire on checkins and other events in the repository, which allows you to do things like send e-mail notifications of checkins, and update your bug tracking system, for example.

So, don’t be afraid to make the jump - Subversion is a vastly improved version control system over VSS. It’s some work to make the conversion and get used to Subversion, but it is a much more capable and higher-quality version control system.

 05 April 2009  software-engineering

Comments on this article