How History Events Are Migrated

  • Article

This topic discusses how the history events that are logged by Visual SourceSafe are migrated into Team Foundation.

History Events

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:

Event 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.

Edit file

The file edit event creates a new version of the file in Team Foundation.

Label file 

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.

Label 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.

Move folder

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:

  • Both source and destination folders are migrated. No data loss. In the previous example, the source $/A and destination $/C folders are both being migrated.

  • Only the destination folder is migrated. After migration, the moved folder appears in the destination folder as if it was added when the folder was moved. The history of the moved folder and the items inside it before the move event is not migrated into Team Foundation. Using the previous example, the move event of subfolder /B will appear in $/C as a folder add event. To prevent loss of history, migrate the source and destination folders of the moved folder together. When you run the migration analysis, the report contains section that will warn you about this data loss.

  • Only the source folder is migrated. During migration, the history of the moved folder, and the items inside it, is not migrated to the Team Foundation. To prevent loss of history, migrate the source and destination folders of the moved Visual SourceSafe folder together. When you run the migration analysis, the report contains a section that will warn you about this data loss.

Note

If the move folder event is combined with a restore event, the history might not migrate properly. For more information, see Visual SourceSafe Converter Limitations.

Share files

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.

Branch files

Sharing is a precondition of branching. The converter cannot map a Visual SourceSafe branch to a Team Foundation source 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.

Archive

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.

Restore

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 source 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.

See Also

Concepts

How the Converter Groups Changesets for Improved Performance

Other Resources

Planning for Source Control Migration