I don’t know if I finally won the battle at my current contract or if the stars just all aligned for me this week. I’m helping the company to takes its first steps away from Visual SourceSafe and into the Subversion realm. Our project has been using SourceSafe for about 5 months now and, as a result, we have a significant codebase stored in it. Part of the migration away from VSS is to ensure that we get all the files, structure and commit history into the new repository.

This being the first time that I’ve done a migration of this nature, I had to research the tools. Here they are in case you have the same scenario.

Subversion server setup: VisualSVN Server. Not only is it free, but it’s so bloody easy to use that I had an architect install it in about 10 minutes and he’d never been exposed to anything related to Subversion before.

Client/Developer tools: TortoiseSVN and WinMerge. Nothing fancy or new here.

Migration of artifacts: VSSMigrate. Great little tool, but it has some config file quirks so make sure to run a trial before doing the real thing. Conversion can be slow…a good reason to do a test run with a copy of the VSS database you intend to migrate from. Our conversion ran without error and it appears that everything was migrated correctly. We did have a simple VSS repository where we’d done nothing more than checkin, checkout, add and delete. We’d also never had a corruption problem either.

We took some steps to get the system into the state we wanted after the conversion was completed. The first thing was to open all the *.sln files and remove the source control bindings from them. They will still be pointing at VSS and there’s no need for that. We also renamed the network share that our VSS database was stored behind. This ensured that no-one could hook up to it and commit changes by accident.

Overall, it’s been a good experience. Here’s to helping more companies make a good decision.