The Source Safe Archive/Restore functionality allows you to inject not just files but history into a database without regard to the history that already exists there. If any of the files or folders happen to share the same name, you can get into a situation where there are 2 files with different contents that, according to the Source Safe history, existed in the same place at the same time.

Team Foundation Server doesn’t allow this and there is no way to tell which revisions belong to which file. There is also no reliable way to tell which actions were restored (vs. the ones native to that server path) or which of the histories is more important to migrate.  Instead, VSSConverter considers the restore action to be the starting point of the database. It will execute a recursive get on the restored folder at that version and add all the resulting files to TFS, then continue to migrate the history from that point forward. 

 

Workaround

In order to migrate the history of files before the restore action you must remove the Restore action from the migration mappings.  To do this you may simply map directly the restored folder and any siblings that you also want to migrate.

For Example:

Let us assume we have a database with two projects $/Project1 and $/Project2   and that $/Project2 was recently restored from another database.  Now you want to migrate the database to TFS with full history. If you were to migrate with a root mapping

<Project Source="$/" Destination="$/TeamProject/" />

The history for $/Project1 would be migrated to $/TeamProject/Project1 but $/TeamProject/Project2 would have only 1 or 2 changesets.

To migrate more history you need to replace it with the following 2 mappings

<Project Source="$/Project1" Destination="$/TeamProject/Project1" />

<Project Source="$/Project2" Destination="$/TeamProject/Project2" />

This would migrate all of the history under $/Project1 and $/Project2 to TFS.

 

Workaround’s Drawbacks

Setting up the mappings this way will ignore all the changes made directly to the mapped folders (not just restore actions).  For example if $/Project1 had been renamed, that rename won’t be migrated. It will always be $/TeamProject/Project1 in TFS.

Setting up all the mappings can get complicated. To get the same results you need to map all the siblings of the restored folder plus the siblings of any ancestor folder.

Even with all folders mapped any files that exist directly in a parent folder (of the restored folder) cannot be mapped. These will have to be migrated manually.