Tips for a successful VSS Import

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Tips for a successful VSS Import

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

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.

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. 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 6.0c, plus the following hotfix from Microsoft:

http://support.microsoft.com/default.as ... us;Q323917

The hotfix is also available at

http://download.sourcegear.com/files/vss_60c_hotfix.zip

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.

You can also use VSS 2005, also called SourceSafe 8.0.

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 -f (fix) option without any errors.

6. 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

<SqlCommandTimeout>3600</SqlCommandTimeout>
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"

Example:

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. Using the Vault Admin tool, select the Server Options tab. Verify that the default setting for IIS File Upload Limit is appropriate for the data in your repository. If you have very large files, you may wish to increase this setting.

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 there is a temp directory in the directory where the SourceSafe database resides. If not, create a Temp directory in the directory that contains the srcsafe.ini file. (The Temp directory and srcsafe.ini file should be siblings.) The cause of this error:
**Failed** to Get version X of Y to upload
is generally because there is no SourceSafe temp directory.

--- Edited to include the latest information from the knowledge base.
--- Edited to include information about ssus.dll
Last edited by ericsink on Thu Jun 10, 2004 12:08 pm, edited 1 time in total.

gaffa
Posts: 36
Joined: Sun Jan 04, 2004 5:37 pm
Location: Melbourne, Australia
Contact:

Something else to consider

Post by gaffa » Sun Jan 04, 2004 5:54 pm

Something else that is worth doing if you have a large database, which I found speeds up the process substantially is to archive off sections of the source VSS db, then restore them to a fresh VSS DB on the import machine, and import that fresh DB.

I had a large (> 2Gb) VSS DB, and progressively archived various branches off the main DB into new VSS DB's. The difference in speed was dramatic - one branch (about 15 projects and maybe 400 files, and a lot of labels) took 23 hours whenb extracted from the master VSS DB, but only 6 when pulled from a fresh VSS DB that only contained that branch.

It's a bit more hands on to run the import, as archiving and restoring is reasonably time consuming. And I've now got about 15 separate VSS DB's on the import machine.....

- gaffa

newmanr19

Re: Tips for a successful VSS Import

Post by newmanr19 » Fri Feb 13, 2004 2:22 pm

ericsink wrote:Do not use SourceSafe 6.0d.
what do you do if your VSS is version 6.0d?

newmanr19

Re: Tips for a successful VSS Import

Post by newmanr19 » Fri Feb 13, 2004 2:23 pm

ericsink wrote:Do not use SourceSafe 6.0d.
what do you do if your VSS is version 6.0d?

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Re: Tips for a successful VSS Import

Post by ericsink » Sat Feb 14, 2004 9:49 pm

newmanr19 wrote:
ericsink wrote:Do not use SourceSafe 6.0d.
what do you do if your VSS is version 6.0d?
Downgrade to 6.0c, at least on the machine where VSS Import is running.
Eric Sink
Software Craftsman
SourceGear

Guest

Re: Tips for a successful VSS Import

Post by Guest » Mon Feb 16, 2004 5:19 pm

ericsink wrote:
newmanr19 wrote:
ericsink wrote:Do not use SourceSafe 6.0d.
what do you do if your VSS is version 6.0d?
Downgrade to 6.0c, at least on the machine where VSS Import is running.
You had me for a minute there. How in the world I thought, would I downgrade a VSS source database? But then I realized you must mean that it's the 6.0c libraries that the Import tool needs as opposed to the acutual source database version?

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Re: Tips for a successful VSS Import

Post by ericsink » Mon Feb 16, 2004 5:24 pm

Anonymous wrote:
ericsink wrote:
newmanr19 wrote: what do you do if your VSS is version 6.0d?
Downgrade to 6.0c, at least on the machine where VSS Import is running.
You had me for a minute there. How in the world I thought, would I downgrade a VSS source database? But then I realized you must mean that it's the 6.0c libraries that the Import tool needs as opposed to the acutual source database version?
Yeah, that's right. You don't need to change your actual database at all, just the version of the libraries being used to access it.
Eric Sink
Software Craftsman
SourceGear

Guest

Post by Guest » Mon Feb 16, 2004 6:42 pm

great; thanks

Guest

Please update import tips for latest version

Post by Guest » Wed Jun 02, 2004 3:32 pm

I see that there have been at least 2 releases of Vault since this subject was last addressed. Could you please update the tips WRT the newest version?

In particular, is it still necessary to avoid SourceSafe version 6.0d?

Thanks.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Wed Jun 02, 2004 3:38 pm

Yes, it is still necessarry to avoid VSS 6.0d. The only signifigant changes for the import tool for Vault 2.0 revolved around the new label system.

arden_dan
Posts: 38
Joined: Thu Apr 01, 2004 2:59 am
Location: Manchester, UK

Post by arden_dan » Thu Jun 03, 2004 7:13 am

Just want to reiterate what gaffa said about archiving VSS databases.

We had a large VSS database which consisted of three major folders, with no shares between them.. however we did merge files between these folders. Approx 10,000 files per folder and nearly 12 months history.

I archived each of the folders individually and restored them into 3 fresh VSS databases. Did the usual Analyze & Fix on the original database and the 3 fresh ones.

Imported the 3 new databases into a single Vault repository. Couple of minor label errors, but nothing destructive. Each import took about 3 hours.

Used two server machines, one with VSS database, VSS client and SV VSS importer.. the other with SQL, IIS6 and vault server.

If you have long histories of large binary files in VSS, they take a long long time to import. We have a translation dictionary, binary format, with over 1500 versions to date. I archived the dictionary history into a separate VSS database to use for reference. I then archived the last months changes and imported only those into Vault.. If we ever need to reference the dictionary history older than a month, we can use VSS.. but these occaisions are rare.

Dan

wchrisjohnson
Posts: 5
Joined: Tue May 25, 2004 3:24 pm
Location: Greenville, SC
Contact:

Where is the hotfix file?

Post by wchrisjohnson » Thu Jun 10, 2004 11:23 am

Hi,

I am preparing to move some of my projects (via the Import tool) from VSS to Vault. I am trying to find the hotfix that was mentioned in the first post in this thread, but the MS site says to contact client support and it isn't on the SourceGear site anymore (the link is broken).

Any ideas?

TIA - Chris

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Re: Where is the hotfix file?

Post by ericsink » Thu Jun 10, 2004 12:10 pm

wchrisjohnson wrote:(the link is broken).
The file moved to:

http://download.sourcegear.com/files/vss_60c_hotfix.zip

and I think I fixed the links to this as well.
Eric Sink
Software Craftsman
SourceGear

wchrisjohnson
Posts: 5
Joined: Tue May 25, 2004 3:24 pm
Location: Greenville, SC
Contact:

Thanks!

Post by wchrisjohnson » Mon Jun 14, 2004 9:02 am

Thanks Eric! That's exactly what I needed.

Chris

bks
Posts: 6
Joined: Fri Aug 20, 2004 12:14 pm
Location: CA, USA

What is the easiest way to down grade to 6.0c

Post by bks » Fri Aug 20, 2004 12:34 pm

I am currently evaluating the VAULT software.

Our VSS source db is installed on a server with 6.0d vss client as will as the VSS admin software (also 6.0d)

The developers (using VS 2003) are still using the vss while I am evaluting VAULT.

How should I go about to test the import to vault?

These are the 3 ways I came up with that I was thinking of exploring, can some one please correct any error in my logic for the 3 ways and point me to the right direction.

1) export VSS db and import it to another machine which has 6.0c install. Then install the import wizard an import from that machine.

2) uninstall the 6.0d on the same server, and just installed the 6.0c. How would this impact the developer who is currently using the db?

3) some how tell the import tool to use a particular directory for the 6.0c obj files. If there is a way to do this.

Tia

Ben

Locked