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.

When I began work at my current employer, they were using Microsoft Visual SourceSafe for version control. This is the tool used by a great many small Microsoft software development shops - when buying an MSDN license to get the development tools, included in the pack is Visual SourceSafe. This makes SourceSafe a no-brainer.

Unfortunately SourceSafe is one of the weakest version control systems ("VCS") around. I won't go into details why not - if you want to know more, I suggest these articles:

• Visual SourceSafe Version Control: Unsafe at any Speed? by Michael Bolton (2003)
• Visual SourceSafe: Microsoft's Source Destruction System by Alan De Smet (2002)
• C2.com's Wiki page on SourceSafe

Some of these pages are quite old now, but so is SourceSafe. It sat at version 6.0 from around the late 90s until 2005 (with a few service packs along the way.) Visual SourceSafe 2005 then arrived, which fixed some of its limitations but without making fundamental changes. So you can still get SourceSafe today and it will have most of the problems and limitations described in the articles above.

So assuming you're now convinced to move away from SourceSafe. To what? This is not a simple question - there are a huge number of version control systems out there.

Your first decision is to make the choice between the classic or distributed flavours of version control. Distributed version control systems - DVCS - are relatively new but have gained a lot of ground in the last couple of years. The highest profile project using a DVCS is Linux. Linux is developed in a highly-distributed fashion, with hundreds of developers all around the world, and a DVCS supports this style of development.

My knowledge of DVCS is limited, so I will refer you Eric Sink, an expert on version control systems, who has very recently written on the subject of DVCS, with some very detailed yet readable articles:

• Git is the C of Version Control Tools
• On Git's lack of respect for immutability and the Best Practices for a DVCS
• DVCS and DAGs, Part 1
• DVCS and DAGs, Part 2
• DVCS and Bug Tracking

For now, I will concentrate back on the classic model of version control. This involves a central server, and each team member checks out from and in to a single central server. There is still a huge choice of software here - for an overwhelming list, see the List of revision control software article in Wikipedia.

However my choice of VCS is undoubtedly Subversion. This open source tool is built on solid VCS principles and has a great ecosystem of supporting tools.

In the next article I will explain how you can migrate your current SourceSafe repository into Subversion.

Edit: this post was originally titled Moving away from Microsoft Visual SourceSafe - Part 1