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.