Options for a VSS import

[lbauer]

There are alternatives to doing a full VSS import into Vault.

As of Vault 5.0.x, you can bring just the latest version of you code into a Vault repository and maintain a connection to your VSS database for VSS history. This feature is called Handoff and can be found in the Vault Admin Web Client.
More on Handoff here: http://support.sourcegear.com/viewtopic ... 13&t=11526


You may not want or need to import your entire Visual SourceSafe database into Vault. Or there may be corruption in the database that prevents a full import. If so, here are some options to consider for moving your source code into Vault:

-- Bring just the latest version of your code into Vault. This isn't really an import. It’s actually a “Get” of the latest version from VSS, using a VSS Explorer Client. Once all the files are on the local drive, use the Vault GUI Client to "Add" the files to Vault. If you want to maintain file shares, this can be done after the import with a special version of the VSS Import Tool.*

You can still access historical source code and labels if you keep your VSS database available.

-- Reduce the size of the import by importing only recent history. Do you really need all 10 years of your VSS history? The VSS Archive utility provides an option to archive off the last X versions of history. Import only recent history and keep the VSS database in case you need to retrieve something earlier.

--Import your VSS database in stages. With the VSS Import Tool you can import one project at a time. This has better chance of success than trying to import the entire VSS database from root. It’s also an opportunity to reorganize your code. If you want to maintain file shares, this can be done after the import with a special version of the VSS Import Tool.*

If you do the import in stages, restart IIS and SQL Server between each import to release memory and flush any caches. Also, backup the database between each import so if something goes wrong, you haven't lost the entire import, just the last project.

If this is a very large import, you may also want to shrink the database and transaction log between imports so that you don't run out of disk space. Be sure to configure the Simple Recovery model for the sgvault database prior to the import, as this will minimize the growth of the transaction log.

-- Clean up VSS database corruption. We recommend running the VSS Analyze utility, with the –c, -v3 (or -v4), and –f options on VSS database prior to import. However, Analyze may not be able to provide a 100% fix If you encounter “file or project not found” errors during the import, try to archive and restore your VSS database, as this process can clear up additional database inconsistencies.

-- Import without Project Security. If you have had many SourceSafe users and your database is several years old, security can take a long time to import. It probably will take you less time to configure new project rights than to import them.

Because it must import all history, the Import Tool creates a user list based on all users in transaction history, not current SourceSafe users. Even though users have long since left the project, the Import Tool will still try to import user rights -- and generate many failures when it doesn't find those rights because the user account is gone.

To avoid this, turn off Project Security for the VSS database prior to beginning the import.


--Import only the labels you need. Recreating labels can take significant system resources and slow add import time. Also, corruption in VSS history can cause a failure in the “Get Label” portion of the VSS Import. The VSS Import Tool provides an option to run the VSS import without importing labels or to import only your most important labels.

--Import labels separately. Another option is to import the labels in a separate operation, after the initial import, using the debug VSS Import Tool.*

--Start over if the import fails. If this is the first import attempt into a new database, we recommend starting over by re-installing Vault and creating a fresh database for the import. Or you can delete the entire repository and create a new one. Don’t re-import over existing data.

*There is a special debug build of the Vault Import Tool than be used to import labels only and to re-establish shares when the import has been done project-by-project. It can also be used when only the latest version of code in VSS has been imported. The debug Import Tool can re-create the shares if the folder structure in Vault matches the project structure that exists in the VSS database.

For more information on the debug version of the Import Tool, contact SourceGear Technical Support.