|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
How History Events Are Migrated
This topic discusses how the history events that are logged by Visual SourceSafe are migrated into Team Foundation.
History events are migrated into the equivalent area of Team Foundation. This lets you maintain the history of your source files. The history of file versions is created by replaying the events that created the history. The following table details how each history event is migrated:
How it is migrated
Add file or folder
The file add event creates the first version of the file in Team Foundation. The folder add event creates the first version of the folder in Team Foundation. If the folder had files or folders under it when it was added, those files and folders are added separately.
The file edit event creates a new version of the file in Team Foundation.
In Team Foundation, you apply a label to a version of a file or folder. In Visual SourceSafe, you can label a file either explicitly or implicitly. When a file is explicitly labeled in Visual SourceSafe, a new version of the file is created and if you do a get of that label, you get the content of the file corresponding to the previous version of the file. To migrate explicit labels, the converter applies the label to the version that corresponds to the labeled version in Visual SourceSafe in Team Foundation. However, it does not create a new version.
When you apply a label of a folder in Visual SourceSafe, the label is applied implicitly all files and folders under the folder, and does not create new versions. For implicit labels, the converter does nothing because the corresponding versions in Team Foundation are automatically labeled during migration of explicit labels on the folder.
In Visual SourceSafe, when you apply a label to a folder, it implicitly labels all the files and folders under that folder, and does not create new versions. During migration of these folders, the converter applies the label to the corresponding version of the folder in Team Foundation. This automatically applies the label to the current versions of files and folders inside the labeled folder.
Rename, delete, or undelete file or folder
During migration of rename, delete, and undelete events of a file or folder, the converter replays the event to create a new version of the file and folder in Team Foundation.
The Move Folder event creates a new version of the folder in Team Foundation. In Visual SourceSafe, the move command does not change the contents or history of the folder, but instead is recorded in the history of the old and new parent folder. When you move a folder, Visual SourceSafe cannot reconstruct an old version of the parent folder.
After migration, you will be able to reconstruct an old version, because of the way the Move Folder event is migrated. For example, if you applied the label "LABEL1" to the folder $/A that has a subfolder /B, and later move /B to another folder $/C; In Visual SourceSafe, and then you do a get of "LABEL1" on $/A, you will not get $/A/B. After migration to Team Foundation, however, you will get the moved folder ($/A/B) when you do a get of the label.
When you are migrating moved folders, there are three possible scenarios that will have different results, depending on what is being migrated:
If the move folder event is combined with a restore event, the history might not migrate properly.
In Visual SourceSafe, you can share a file across multiple folders. Changes that you make in a shared file are replicated across the folders where it is shared. Internally, Visual SourceSafe creates soft links between shared files. Folders are not technically shared in Visual SourceSafe. When you share a folder in Visual SourceSafe, a copy of the folder is created and all the files in the folder are shared.
Team Foundation does not have an equivalent of sharing. Shared files are migrated by creating a version in the destination folder with the same content as the version of the file at the time when sharing began. From this point forward, the changes made to the shared file are replicated to both places by converter.
Share and delete file
A file that is shared and then deleted is handled as a shared file, except that all the actions after the delete are ignored.
If the deleted shared file is undeleted later, the converter reports errors during migration for each action, such as edit or rename. However, during the migration of the undelete action, the converter does an undelete-edit of the file so that it has the same content as the content of undeleted file in Visual SourceSafe.
If the deleted shared file is renamed later, the converter reports errors during migration of the rename action. Actions after the rename will not migrate and the converter reports error for each action.
Sharing is a precondition of branching. The converter cannot map a Visual SourceSafe branch to a Team Foundation version control branch. The migration of a shared file results in replica of the file in the destination folder. Migration of branch events mean the changes made to a shared file are not replicated to both places any more. Therefore, the changes to any branch are migrated to the respective copy in Team Foundation. The migration report provides a list of folders containing files that are either shared or branched in Visual SourceSafe.
When you archive files or folders in Visual SourceSafe, you can either remove the history of a file or folder completely, or remove some versions from the history of a file or folder. If you have removed the history, the converter cannot migrate the removed versions. The converter ignores the Archive event.
When you restore in Visual SourceSafe, you restore the history of an archived file or folder. The converter migrates the restored history of files and folders. The converter ignores the Restore event.
PIN and UNPIN
Team Foundation version control does not support pinning; therefore all pinned files are migrated by creating two labels. The PINNED_LATEST label is applied to the pinned versions of the pinned files and the latest version of the unpinned files. The PINNED label is applied to only the pinned versions of the pinned files. After migration, the PINNED_LATEST label will retrieve the same files as a Get Latest in Visual SourceSafe. However, the PINNED_LATEST label might return different files, if events other than check in occurred after a file was pinned, such as rename or a deletion of the file.