VSS to Subversion: What to migrate?

In what amounts to my first round of general musings about migrating a Microsoft Visual SourceSafe repository into Subversion, its clear that one critical decision affects the entire process: What will you migrate?

The question sounds simple on the surface, but once you begin to peel away the avacado layers from both Subversion and SourceSafe, you find that the differences in the storage philosophies of either make that decision much more critical up front.

The simplest type of migration is to "Get Latest" to snag the contents of the latest revision of each SourceSafe project, create a Subversion folder to host the migrated copies, and perform an "svn add" to pull the files into Subversion. That's the clear choice if you're not worried about migrating any of SourceSafe's history and want to create a new source control start point with Subversion. It's also a migration you can accomplish in a day or less. If you want that history, however.....

Migrating SourceSafe's history requires delving much more deeply into the way it stores and tracks changes, and reconciling that against how Subversion does the same thing. Doing that reveals more of the inherent fundamental differences in the way the two tools operate, and gives you a first-level notion of how hard it is to get that history into Subversion.

Subversion stores sets of changes to multiple files and/or folders as transacted sets of changes. Each set of changes is assigned a revision number. SourceSafe tracks changes on a per file basis, storing the entire revision of each file in each change. That means that each and every change could be migrated as a single revision into Subversion, making for a huge repository that is 99.9% changes, or that those changes must be aggregated in some way that bears no relationship to any native structure from SourceSafe.

A nice open-source migration tool, VSSMigrate, tries mightily to do that for you. We'll talk about that next time.

MIgrating VSS to Subversion

If you're a long-time Microsoft development shop, chances are you've had to deal with its source control tool, Visual Source Safe. After years of wrangling with VSS and dodging the bullets of corruption and loss that have formed its reputation over the years, I'm undertaking the task of migrating our VSS repository to Subversion. Yeah, I evaluated Team Foundation Server, but it was just too much.

Don't know how many out there might be contemplating the same task, but I'll be posting a few musings here and there about my progress, obstacles, tools, and lessons learned along the way. Hopefully, something I encounter will help someone else.

For starters, the Subversion repository will be entirely Windows-hosted - unfortunately, slapping Subversion on a Linux server (which is my preferred option) just isn't going to work. Also, I'll be installing the TortoiseSVN repository client and the AnkhSVN source control plug in for Visual Studio. And I've already taken quite a few steps in migrating the repository with the C#-based open-source tool VSSMigrate, which is hosted on CodePlex, and uses the SharpSVN .NET-based Subversion API. Considering that I'll have an objective of migrating just about everything in VSS, including deleted (but not purged) items, I suspect the process even with VSSMigrate will be tedious.

As I post my progress, feel free to post any questions or thoughts you may have as I Go Forth and Migrate - and hopefully wean away from SourceSafe!