Understand how VSS upgrade tools convert your data
The Visual SourceSafe upgrade tools are a convenient method for a one-time, one-way upgrade of your codebase from Visual SourceSafe to Team Foundation Server (TFS). You should use the tools to upgrade your data only when you are ready to stop accessing it in Visual SourceSafe and begin maintaining it in TFS.
TFS and Visual SourceSafe have significant functional differences. As a result, the Visual SourceSafe upgrade tools modify certain kinds of data during the upgrade.
In this topic
How changesets are created
How shared and pinned items are upgraded
How historical data is ported
How data about the user name and the time stamp is ported
How specific types of events are converted
How version control bindings are ported
How changesets are created
TFS version control groups changes to multiple files into a single unit when a user checks in a set of changes. This single unit is known as a changeset.
Visual SourceSafe does not have a feature that is equivalent to changesets. However, during the conversion process, each set of changes is grouped into a changeset as long as the following conditions are true:
The changes do not conflict with each other. For example, no two actions affect the same file or folder.
The changes occurred within no more than a few minutes of each other.
The changes were checked in by the same user.
The changes have the same check-in comment.
How shared and pinned items are upgraded
In Visual SourceSafe, you can share a file across multiple folders. Changes that you make in a shared file are replicated across the folders in which the file is shared. TFS version control does not have an equivalent feature. During the upgrade, shared files in your Visual SourceSafe project are upgraded by creating an additional independent copy of the item on your server for TFS version control.
TFS version control also does not have a feature that is equivalent to the Pin feature in Visual SourceSafe. During the upgrade, pinned items in the Visual SourceSafe project are converted to labeled items on your server for TFS version control. For more information, see the next section.
How historical data is ported
Each event in the history of an item in your Visual SourceSafe database is transferred onto your Team Foundation Server as a changeset. After the upgrade is completed, you can view this data in the History window. For more information, see Get the history of an item.
Some changes to the data occur during upgrade.
How data about the user name and the time stamp is ported
As each entry in the history of an item in your Visual SourceSafe database is upgraded to a changeset on your Team Foundation Server, the following changes occur:
The time stamp on the changeset is set to the date and time when the item was upgraded.
The original time stamp is stored in the Comment field of the changeset.
The user name is stored in either the User field or the Comment field of the changeset, depending on the result of the user mapping process.
Note
If you want to control how user names are assigned to historical data, you must use VssUpgrade. See Specify how user names are upgraded.
How specific types of events are converted
Events such as edit, rename, and delete are upgraded from your Visual SourceSafe database into changesets on your Team Foundation Server in a straightforward manner. However, the upgrade tools convert some events in ways that you might not expect, as the following table shows.
Visual SourceSafe Event |
How it is upgraded into TFS version control |
|---|---|
Add file or folder |
This changeset is the first event in the history of each upgraded file and folder. Unlike in Visual SourceSafe, no event is logged for the parent of each child item that it contains. |
Branching |
Sharing is a precondition of branching in Visual SourceSafe, but TFS version control does not support sharing. Therefore, the upgrade of a branched file creates a copy of the file in the destination folder. The shared files in your Visual SourceSafe database are upgraded to TFS version control by copying the version of the file that existed when it was shared and putting the copy in the destination folder. Thereafter, each changeset is replicated in both copies of the file until the branch event occurs. |
Label |
Implicitly labeled items: In Visual SourceSafe, when you label a folder, the items it contains are implicitly labeled. The upgrade process explicitly labels all the upgraded items in your team project. Explicitly-labeled files: In Visual SourceSafe, when you explicitly label an individual file, a new version of the file is created. The upgrade process ports the label to the applicable version in TFS version control, but it does not create a new version. Note If your Visual SourceSafe database contains many labels that are applied to many files, the upgrade process may be prolonged. If you want to exclude this data, you must use VssUpgrade and configure it to ignore labels. See <Label migrate="false" />. |
Move folder |
The Move Folder event creates a new version of the folder in TFS version control. If you are using VssUpgrade, it will not upgrade the complete history of items in moved folders unless both the source and destination folders are upgraded at the same time. See Review and resolve issues found by the analyze feature. Note If the move folder event is combined with a restore event, the history data may not be upgraded correctly. |
Restore |
No history data that occurs before a restore event is upgraded. |
PIN and UNPIN |
TFS version control does not support pinning. The upgrade tools upgrade a pinned file by creating two labels. The PINNED_LATEST label is applied to the pinned versions of the pinned files and to the most recent version of the unpinned files. The PINNED label is applied to only the pinned versions of the pinned files. After upgrade, the PINNED_LATEST label will retrieve the same files as a Get Latest in Visual SourceSafe. However, one exception is that the PINNED_LATEST label might return different files if events other than checking in occurred after a file was pinned, such as renaming or deleting the file. |
Sharing |
TFS version control does not support sharing. Shared files in your Visual SourceSafe database are upgraded to TFS version control by copying the version of the file that existed when it was shared and putting the copy in the destination folder. Thereafter, each changeset is replicated in both copies of the file. |
Undelete File or Folder |
During an upgrade of undelete events of a file or folder, the tools replay the event to create a new version of the file and folder in TFS version control. The upgrade tools create a changeset that includes the file or folder name, the date and time when it was undeleted, and the user name. |
How version control bindings are ported
The upgrade tools port version control bindings for each solution.