Team System

Importing Visual SourceSafe databases into Team System

Team System includes a dedicated utility for importing your existing Visual SourceSafe databases into Team System source control:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VSSConverter.exe

Eric Jarvi has a good walkthrough for using VSSConverter, but it's a little antiquated now. Let's bring it up to date with a fresh import using the release candidate.

Before we get started, a few prerequisites:

1. You must have Visual SourceSafe 2005 installed on the machine you're running VSSConverter from. Unfortunately, VSSConverter has some dependencies on DLLs in VSS 2005. You can uninstall VSS 2005 once you're done with the migration, but you must have it installed when running VSSConverter.
2. You must have SQL Express installed and enabled on the machine you're running VSSConverter from. This isn't exactly obvious from the documentation, but VSSConverter uses the local SQL instance as a scratch database during the conversion. If there's no local scratch database, the migration will bomb with cryptic SQL errors. We burned a couple hours troubleshooting this, when it turned out that SQL Express was simply disabled on the PC. Doh!
   

There are two primary commands for VSSConverter: analyze, or migrate.

VSSConverter [/?|h|help] [analyze|migrate] [settings_file]

 analyze                Analyze VSS repository
 migrate                Migrate VSS repository
 settings_file          Name of settings file
 /? , /h or /help       Display above help

Example:
  > VSSConverter analyze settings.xml .... Starts Analysis
  > VSSConverter migrate settings.xml .... Starts Migration

Instead of passing a bunch of cryptic command line switches, we pass.. a bunch of slightly-less-cryptic XML. Here's a skeleton template for the analysis settings:

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
  <ConverterSpecificSetting>
    <Source name="VSS">
      <VSSDatabase name="d:\vss-test\"></VSSDatabase>
    </Source>
    <ProjectMap>
      <Project Source="$/" ></Project>
    </ProjectMap>
  </ConverterSpecificSetting>
</SourceControlConverter>

Edit this to taste and save it as analyze.xml.

Now we'll analyze the Visual SourceSafe database to make sure nothing bad will happen during the migration. We hope, anyway..

VSSConverter analyze analyze.xml

Initializing...
VSS administrator password:

Scanning $/
Scanning $/ConsoleApplication4.root
[ list of scanned files omitted ]
Analyze complete.
Analyzed 9 files and 5 folders.
Warnings 2 and Errors 0
Pre-migration report file: VSSAnalysisReport.xml

The analysis produces VSSAnalysisReport.xml:



As long as nothing catastrophic was revelaled during the analysis, we can proceed to the migration.

Like the analysis, migration settings are provided via an XML input file. Here's a skeleton template:

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
  <ConverterSpecificSetting>
    <Source name="VSS">
      <VSSDatabase name="d:\vss-test\"></VSSDatabase>
      <UserMap name="UserMap.xml" />
      <!--<SQL Server=".\SQLExpress" /> -->
    </Source>
    <ProjectMap>
      <Project Source="$/" Destination="$/Demo/Main/"></Project>
    </ProjectMap>
  </ConverterSpecificSetting>
  <Settings>
    <TeamFoundationServer name="TeamSystem" port="8080" protocol="http"></TeamFoundationServer>
  </Settings>
</SourceControlConverter>

Edit this to reflect the correct values for your setup, and save the file as migrate.xml.  The analysis also produces a file, UserMap.xml, which lets you map SourceSafe users to Team System users. You'll want to edit that, too.

One caveat: the Team System destination folder you specify must be empty or the migration will complain, and abort. Luckily, if you provide a folder name that doesn't exist, it'll automatically be created for you.

Let's attempt the migration:

VSSConverter migrate migrate.xml

Initializing...
This will start migration with following inputs:

SourceSafe Folders -> Team System Folders
$/ -> $/Demo/Main
VSS Database: d:\vss-test\srcsafe.ini

Team Foundation Server: http://teamsystem:8080/
Migration Settings File: migrate.xml
Migration Report: VSSMigrationReport.xml

Depending on the VSS database size, migration may take few hours to complete.
Please verify all inputs are correct and confirm.
Start migration (Y/N)?y

VSS administrator password:
Connecting to Team Foundation Server.

Scanning $/ for migration
[ list of scanned files omitted ]

Migration complete.
Migrated 22 Actions
Warnings 2 and Errors 0
Post migration report file: VSSMigrationReport.xml

The migration produces VSSMigrationReport.xml:



Here's what the newly migrated project looks like in Source Control Explorer:



Indeed, it's identical to the Visual SourceSafe data, comments and all!



However, VSSConverter isn't magic -- it can't convert everything. If you've used branching, sharing, or pinning in Visual SourceSafe, don't expect that to convert well:

• Sharing is not supported in Team Foundation source control. Shared files are migrated by copying the version of the file at the time sharing began to a destination folder. From then on, the changes made to the shared file are replicated to both copies.

• Branching a file. Because sharing is a pre-condition of branching, the migration of a shared file results in copying the file to the destination folder. After the branch event, the changes to any branch are migrated to the respective copy in Team Foundation source control.

• Pinning is not supported in Team Foundation source control. To help you locate items in the Team Foundation source control repository that were once pinned in the SourceSafe database, the converter tool assigns a “PINNED” label to the version that was pinned

We've imported a few VSS projects into Team System now, and the main problem we've run into is with branching -- you don't get any file comments past the last branch.

Of course, in my opinion, if you use branching in VSS, you're asking for problems, but that's an entirely different story..