# Tuesday, November 24, 2009

Recently, I was asked to migrate code from one source control repository to another.  The customer had been using Visual Source Safe (VSS) for many years and had dozens (maybe hundreds) of projects checked in. Most of these projects had a long history of file versions.
VSS was a decent product when it was first released, but it falls far short of newer source control systems, such as Team Foundation Server (TFS), Subversion and CVS. This customer selected TFS as their new source control system, but they did not want to lose the history they had captured in VSS.

They asked me how to move the years of VSS history into TFS. Tools exist to do this, including  Microsoft’s VSS2TeamFoundation (available at  http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx). However, migration tools have several disadvantages:

  1. Migrating years of source control can take a really long time, maybe weeks. You will probably want to do a test migration of your data, which will extend the time requirement even further.
  2. If you have been checking code into a source control system for any length of time, there are bound to be some mistakes: Projects that were started but never went anywhere; Code changes that were mistakenly checked in and had to be reverted; and duplicate source code erroneously checked into two distinct folders. If you migrate your all source code history, these mistakes will be migrated as well.

A simpler alternative to migrating every version of every project in every folder is to simply get the latest code from the old source control repository and check it into the new repository. Using Visual Studio, this requires only a few steps:

  1. Open the project in Visual Studio
  2. Get latest from the old source control system
  3. Remove bindings to the old source control system
  4. Connect to the new source control system
  5. Check the code into the new source control system

Repeat this for each solution. You will now have a current version of all relevant code checked you’re your new source control system.

Some users will tell you this is not enough. These users want to keep all the history of every bit of code - every version, every branch and every project. Using the above migration strategy, you can still do that. My recommendation is to keep the history in your old repository, mark that repository as read-only and leave it online. Users will still be able to use this old source control system to find their old code, but will use the new source control system for all version control going forward. This is far simpler and faster than trying to push years of changes into a new repository.

The lesson here is: Always consider the simplest alternative and determine whether it meets your needs, before considering more complex solutions.