Take Next Steps after Upgrading from Visual SourceSafe

Article
09/28/2012

After the upgrade has been completed, you should make sure the results meet your expectations and that the data is ready for your team to use:

Check the outcomes from the upgrade process
Resolve problems
- Resolve failure caused by storage limit for SQL Server Express
- Convert files in the MS-DOS-Compatible short name (8.3) format (TF227014)

Check the outcomes from the upgrade process

Review the report and if necessary, the logs that were generated by the upgrade tool. Check the data on your Team Foundation server to make sure that the data from your Visual SourceSafe database was upgraded in the way that you expected.

View the Migration Report

TFS and Visual SourceSafe have significant functional differences. As a result, the Visual SourceSafe upgrade tools modify certain kinds of data during the upgrade. And in some cases, errors or problems might occur. The migration report can advise you about these kinds of issues.

To open the migration report:

If you used the VSS Upgrade Wizard: On the Complete page, choose the Upgrade Report link.
If you used the VssUpgrade tool: Open the VSSAnalysisReport.xml report in the current directory, or whatever file name and location you specified using the <Output file> attribute.

Migration Report

View logs

If warnings or errors were reported, you might want to view the logs. You might also want to view the logs to get details on how your data was modified during the upgrade process. To view the logs:

If you used the VSS Upgrade Wizard: On the Complete page, choose the Complete Log link.
If you used the VssUpgrade tool: Open ConverterErrors.txt and VSSUpgrade.log.

Check the data in your team project

Use source control explorer to check the data on your Team Foundation server to make sure that the data from your Visual SourceSafe database was upgraded in the way that you expected.

Resolve problems

After you have checked the outcomes of the upgrade process, you may have to troubleshoot problems.

Resolve failure caused by storage limit for SQL Server Express

The upgrade tools use a database to store temporary metadata. This metadata typically requires a small percentage of the total size of the data that you upgrade. In the unlikely event that your upgrade fails because the 4-GB limit of SQL Server Express is reached, you can use SQL Server instead of SQL Server Express. See Upgrade from Visual SourceSafe Using the Wizard or VssUpgrade <SQL> Element.

Convert files in the MS-DOS-Compatible short name (8.3) format (TF227014)

TFS does not allow file names that are in the MS-DOS-compatible short name (8.3) format (for example, abcdef~1.txt). When you analyze or attempt to upgrade files that have such a name, a TF227014 error appears.

To work around this issue, you can temporarily apply a setting to your Team Foundation Server that will cause it to allow files that have such names. To do this, you must set Allow8Dot3Paths to True in the configuration database for TFS.

Important

To avoid issues with client machines that support MS-DOS-compatible short names, after you complete the upgrade process, it is strongly recommended that you set Allow8Dot3Paths to False as described in the following procedure.

To perform the following procedure, Windows PowerShell must be enabled on the application-tier server for TFS. See Scripting with Windows PowerShell.

Required Permissions

To perform this procedure, you must be a member of the Administrators group on the application-tier server for TFS. For more information, see Team Foundation Server Permissions.

To upgrade a Visual SourceSafe database that contains files that are named in the MS-DOS-compatible short name format

Log on to the application-tier server for Team Foundation.
Create a Windows PowerShell script that is called Allow8Dot3Paths.
1. Copy the text in Allow8Dot3Paths PowerShell Script later in this topic, and paste the text into the script.
2. Change ServerPath to match the path in the URL that you use to connect to Team Foundation Server. By default, the server path is "tfs".
3. Change CollectionName to match the name of the team project collection into which you are upgrading your data (for example, DefaultCollection).
  
  The end result, for example, would be the following line in the script:
```
$collectionBaseUrl = "https://localhost:8080/tfs/DefaultCollection/";
```
Run the Allow8Dot3Paths script.
Recycle the application pool for your Team Foundation Server.
1. From Windows Start run Computer Management.
2. In the navigation pane, expand Services and Applications.
3. Choose Internet Information Services (IIS) Manager, expand the local computer, and double-click Application Pools.
4. Open the shortcut menu of the application pool, and then choose Recycle.
Run the Migrate command.
Modify the Allow8Dot3Paths Windows PowerShell script that you created earlier, replacing "true" with "false".
Run the modified Allow8Dot3Paths script.
Recycle the application pool for your Team Foundation Server (as explained above).
In Visual Studio, if you are not already connected, then connect to the team project into which you upgraded the data.
In Source Control Explorer, rename any files that have names in the MS-DOS-compatible short name (8.3) format.

Allow8Dot3Paths PowerShell Script

# Load client OM assembly.
[Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");

$collectionBaseUrl = "https://localhost:8080/ServerPath/CollectionName/";

$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);
$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);

# Set some version control settings in the collection hive.
$collectionHive.SetValue("/Service/VersionControl/Settings/Allow8Dot3Paths", "True");

# Display all version control settings as a table.
$collectionHive.ReadEntries("/Service/VersionControl/Settings/...") | ft -a

Share via