Tips for a Successful VSS Import

A collection of information about Vault, including solutions to common problems.

Moderator: SourceGear

Post Reply
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear

Tips for a Successful VSS Import

Post by ericsink » Wed Dec 17, 2003 10:32 am

NOTE: This KB article applies to Vault/Fortress VSS Import Tool.

For Vault's VSS Handoff tips, see this KB article: ... 13&t=11526

Handoff is available in Vault 5 and later versions.

Importing a SourceSafe database into a Vault repository is a big operation. In some cases, the full import can take several days, so it's worth making sure that everything is configured properly at the beginning. A little careful planning can avoid a lot of frustration.

Even so, the full import may experience many errors and missing data. the VSS Import Tool uses the SourceSafe Automation Component to communicate with the VSS database. The automation component is very sensitive to VSS database corruption, and even minor corruption can cause problems with getting VSS history which may not be imported into Vault.

The following tips will help your import go as quickly and as smoothly as possible.

1. We recommend that you use two different machines. One machine should be running the Vault server, including SQL Server. The other machine should be running the VSS Import Tool, and your VSS database should be on that machine as well. The import will go much faster if both these machines have plenty of RAM and fast hard disks or SSDs. The network connection between these two machines should be fast, at least 10-baseT and preferable 100-baseT. Ideally, neither machine should be occupied with any other tasks during the import.

2. During the import, you should disable any virus protection which may be present on either machine. This can slow down the import considerably.

3. On the machine with the VSS database, you should be running the English language version of SourceSafe 2005, also called SourceSafe 8.0. Make sure you have installed the VSS 2005 Update: ... spx?id=291.

If you use Visual SourceSafe 6.x, please use SourceSafe 6.0c, plus the following hotfix from Microsoft: ... us;Q323917

The hotfix is also available at

Do not use SourceSafe 6.0d or non-English language versions of SourceSafe.

Some users have had problems with non-English versions of SourceSafe, so use the English language version. You can verify that you are using the English version of SourceSafe by examining the directory with the ssapi.dll file. The only language dll in that directory should be named ssus.dll.

4. Do not continue to use your SourceSafe database during the import. In fact, it is best if you run the import on a backup copy of the database, not on the copy you usually use.

5. Be sure to run the SourceSafe 'analyze' utility on your database before doing the import. If your VSS database is not healthy, you are likely to run into problems when retrieving files during the VSS import. A properly running database should be able to run the VSS 'analyze' with the -c (compress), -v3 or -v4 (verbosity) and -f (fix) option without any errors.

6. For versions prior to 4.x: Make sure the IIS doesn't get confused and kill ASP.NET during long operations. In your machine.config file, look in the processModel section and find the setting called responseDeadlockInterval. The default value is three minutes. We recommend changing it to at least an hour.

7. In Vault's Web.config file, there is a setting called executionTimeout. We recommend setting this timeout to at least an hour.

8. In Vault's Vault.config file, there is a setting called SqlCommandTimeout. We recommend setting this timeout to at least an hour. Example:

Code: Select all

If SQL Server response is slow, you can also increase the Vault Server connection timout in the Vault Service web.config file. Add this value to the end of the connection string: "Connection Timeout=120"


Code: Select all

<add key="ConnectString" value="Application Name='SourceGear Vault Server'; Connection Reset='true'; Server=(local); Database=sgvault; Integrated Security='true'; Connection Timeout=120" />
9. Are IIS and Vault configured to allow large files? By default, IIS will only allow file uploads of ~30MB and Vault ~100MB. Check that both IIS and Vault are configured to a value if you have larger files within VSS.

a) For Vault, using the Vault Admin Web Client, select the Advanced Settings tab. Verify that the default setting for IIS File Upload Limit is appropriate for the data in your repository.

b) For IIS, you will need to increase the HTTP request size found for your specific version of Internet Information Server. See viewtopic.php?t=21824 for additional details.

10. Manage the size of SQL Server files to avoid running out of disk space. If SQL Server is in Full Recovery model, the transaction log can become very large due to all the transactions by the Import Tool. Prior to the import, configure the sgvault database to use Simple Recovery backup model. This will minimize the growth of the transaction log.

Also in sgvault properties->Files, set the database to autogrow by a certain number of MB, not by a percentage, as this can also cause unwanted increase in database size if it grows by 10%, for instance, each time it needs more space.

11. You should make sure that IIS is configured to allow anonymous access to the VaultService directory. This does not compromise security, as you are merely instructing IIS to allow Vault to handle its own authentication.

12. Before doing the import, you may wish to review your VSS database and purge any items which have been deleted and are no longer needed as part of a past label.

13. Note that importing labels can be very slow. You may wish to import only those labels which you actually need. This is especially true in Vault 1.x.

14. Some users have reported import problems when keyword expansion is enabled in Vault. Prior to your VSS import, change your repository options to deny keyword expansion.

15. Make sure the directory for "Temp_Path" found in srcsafe.ini exists. By default, srcsafe.ini's "Temp_Path = temp", so there should be a temp\ sub-directory found in the directory where the SourceSafe database resides (i.e. where srcsafe.ini is located). If not, create a directory that matches the value found for Temp_Path. For example, using the default directory setting as a guide, create a "temp" new sub-directory located in the directory that contains the srcsafe.ini file if it does not exist. (The "temp" directory and srcsafe.ini file should be siblings.) Or if the Temp_Path value is an absolute path, then verify/create all directories for that absolute path.

The cause of this error:
**Failed** to Get version X of Y to upload
is generally because there is no SourceSafe temp directory.

Post Reply