Migrate from Visual SourceSafe (VSS) to Team Foundation Server

 

 

If you current organization is currently using MS Visual SourceSafe (VSS), then they are certainly in luck when it comes to upgrading to Team Foundation Server. Team Foundation Server 2010 comprises a migration tool that can migrate the fully from a VSS to Team Foundation Server. This tool contains several features that will support an admin in migrating source code easily from the VSS. Below are the features:

As stated earlier, a team may find themself looking at a situation where they will likely to not get support from MS if there were a disastrous DR problem that causes data loss from VSS repository. The VSS Converter tool plays back each of the check-ins into Team Foundation Server during the migration. It does so by makingchangesets of fi  les that were checkeredin at relatively the similar time by the same user and with the same comment. Also, the fluctuationsneed tonot conflict with one another to be comprised in the same changeset.

One of the results that will be noticed is the fact that the date and timestamp for the new changesets will be set to the time that the migration act actually occurred, instead of the original time. The original check-in date and timestamp will be stored in the changeset ’sstatement for reference purposes. Furthermore, the original user will not be stowedin the statement if that user is not mapped properly. If the user is mapped properly, the username will be in the changeset’s username field.  This unitlook at the different options that teams have offered if they want to migrate the full history from VSS into the Team Foundation Server version control repository.



VSS Converter Tool

The very first step beforehand attempting to begin a migration exertion is to confirm that the VSS repository has been fully backed up. This offers the ability to restore it to its original state if there are any major errors that may take place during the migration. Be sure to constantly run the migration tool against a secondary copy of the DB, not the primary liveDB. One key step is to confirm that, if the VSS DB version is older than the newest version (Visual SourceSafe 2005), then the DB should be upgraded prior to the migration. The DDUPD tool can be used for upgrading to the newest version after installing Visual SourceSafe 2005. During the investigate phase, the VSS Converter tool will check whether the DB has been upgraded correctly prior then it proceeds to the migration implementation phase. The development team may select to not migrate all of the history that is stored in the VSS repository, and instead choose to migrate only a subset of that history. The VSS Converter tooloffers a mechanism for stating a start timestamp or label, and will begin migrating from the oldest available check - in to the newest in sequence. A team might choose that they only want the last years’worth of history to decrease the amount of migration execution time that is needed. If that is the case, then the admin should use the archive ability that is available in VSS to archive all content prior to the selected date.    

For those instances where migration execution time wishes to be minimized as much as possible, confirm that all of the servers and systems needed in the migration exist on the same VLAN. The servers and systems that will be used in the migration effort remain the migration system that will be performing the VSS Converter tool, the server hosting the file share that comprises the VSS DB, and the Team Foundation Server 2010 server. Finally, arrange the team for the migration by advising them of the time frame of when the migration will happen. Preferably, the team will have checked in all files, removed any check  -  outs, and not used the VSS DB during the migration. To confirm that only the migration tool has access to the repository, permissions can be removed from the file share for all users but not the account running the migration.



Analyze VSS Repository

After the groundwork steps have been taken for a VSS migration, the next step is to use the Analyze function in the VSS Converter tool to determine any possible issues that should be addressed beforehand the migration phase can continue.  To begin the examine phase, a file is created with the appropriate settings to provide the VSS Converter toolenough info about the planned migration to check for possible issues. The VSSDBnode is used to stipulate the folder location that contains the   srcsafe.ini  file. Though, do not state   srcsafe.ini   in the value that is identified. The   UserMap   node is what is used for identifying where to store the user mapping file that will be produced by the   Analyze   function. If no user mapping file is specified, then the VSS Converter toolwill create one in the operational directory with the name of   UserMap.xml . The   ProjectMapsegment describes the location of each folder in the VSS repository that will be used as the source locations throughout the migration phase. Make sure you include each of the locations you aim to use during the migration phase; else, they will not be included throughout the analyze phase.

Finally, the Ouput  node is used to identify the name and location of the output fi le that should be shaped from the Analyze  file. Be sure to name this in a different way from what will be used during the migration stage so that you can have a copy of both after the migration has accomplished.   The   Analyze   function for the VSS Converter tool can start by executing the following exe from a Visual Studio 2010 command prompt, where  VSSAnalyzeSettings.xml     is the name of the   Analyze  settings fi le that was created earlier:

 VSSConverter.exe Analyze   VSSAnalyzeSettings.xml

The analyze phase can take a while;watch it carefully make sure no error occurs. This permits the admin to resolve those issues and initiate the analyze phase again to start from the point where it left off.  



Execute the Migration

The Migratetask for the VSS Converter toolcan start by executing the following exe from a Visual Studio 2010 command prompt, whereMigrateSettingsVSS.xml     is the name of the migration locale file that was generated earlier:

VSSConverter.exe Migrate   MigrateSettingsVSS.xml

The migration execution stage can take a substantial amount of time, dependent on the amount of source code, number of migration actions, and network speed. It should be watched for possible issues that may come up. If an error does occur throughout the migration phase, the VSS Converter toolcan started again from that point, and canstart once again. Simply state that you want it to continue as an incremental migration when provoked, and the tool will continue from where it left off. Later the migration tool has finished, the Team Foundation Server version control repository is prepared to be used by the devteam.