Tips for a successful VSS Import

lbauer · Post by **lbauer** » Tue Oct 11, 2005 2:18 pm

We still recommend VSS 6.0c with the Microsoft Hotfix from this link:
http://download.sourcegear.com/files/vss_60c_hotfix.zip

This version's automation component has been tested extensively with SourceGear products and tends to be the most reliable.

Later versions of VSS are not necessarily better for the import. For instance, the threading model was changed in VSS 6.0d (ssapi.dll version ending in 98.48 ) which causes that Automation Component to crash during concurrent operations.

adje · Post by **adje** » Wed Jun 21, 2006 3:17 am

Is using VSS 8.0 just as good as version 6.0c or is the latter still recommended?

Another question that I have is about exporting VSS. Does the VSS dababase needs to be locked, or can people continu to use VSS while exporting?

Thanks in advance,
Adje

lbauer · Post by **lbauer** » Wed Jun 21, 2006 6:36 am

Is using VSS 8.0 just as good as version 6.0c or is the latter still recommended?

We have done some testing with VSS 8.0, though not as thoroughly as with 6.0c. We didn't run into any problems, so you should be able to do your import with VSS 8.0.

It's best if users are locked out of VSS during the import. You don't want modifications being made to the VSS database while the VSS import tool is running.

brendang · Post by **brendang** » Fri Sep 29, 2006 1:10 am

Hi all,

Since people have been asking questions in this thread, hopefully this is in the right place.

I've been attempting to import our VSS database into Vault. Anytime I do so, I get the following exception in the log file:

Beginning Export. 29/09/2006 4:56:24 PM
Begin Export....

Unhandled exception during export: Process performance counter is disabled, so the requested operation cannot be performed.
Trace: at System.Diagnostics.NtProcessManager.GetProcessInfos(PerformanceCounterLib library)
at System.Diagnostics.NtProcessManager.GetProcessInfos(String machineName, Boolean isRemoteMachine)
at System.Diagnostics.ProcessManager.GetProcessInfos(String machineName)
at System.Diagnostics.Process.EnsureState(State state)
at System.Diagnostics.Process.get_PrivateMemorySize()
at VSSImport.WizardForm.ExportPassTwo(Hashtable vssUsers)
at VSSImport.WizardForm.Export()
Logged out of the Vault Server.

1. I have a copy of the VSS database on the same machine that I'm running the import tool on.
2. The Vault Server is on the same machine that I'm running the import tool on.
3. We're running Vault 3.1.8.3771
4. I'm logged onto the machine with an account that's a machine admin.
5. ASP.NET is running under a domain account (for Active Directory Auth), and is also a member of local machine admin.
6. I've got VSS 6.0c on the machine.

The import tool completes and says that there were no errors, but the log file shows different. Nothing is imported at all.

I've been banging away at this for the better part of the day, so any help would be appreciated.

Thanks and Regards,
Brendan Green

lbauer · Post by **lbauer** » Sun Oct 01, 2006 2:55 pm

Process performance counter is disabled, so the requested operation cannot be performed.

This error could be due to a setting in the registry.

Please look under this registry key on your machines: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance

and see if there is an entry named "Disable Performance Counters."

If so, remove it and see if the import can proceed.

brendang · Post by **brendang** » Sun Oct 01, 2006 4:20 pm

Hey, worked a charm.

Thanks for the quick response!

mbainbridge · Post by **mbainbridge** » Mon Nov 06, 2006 8:21 am

Ever since the first release of Vault I've been trying to get our broken 30GB VSS database to import. I know there's not a snowball's chance of getting the whole thing across in one go, but I've finally managed to get something across for the first time

I found a couple of the points below by searching the forums for obscure error messages, so I've collected them in one place. Hopefully, it might help someone with a successful import:

1) Use a proper installation of VSS. In previous testing, I'd been using a Netsetup installation, and the best I got was to import the project tree but no files. As soon as I installed VSS from the original CD, I got everything!

2) Turn off project security. In our database, I'd noticed that some users had rights for projects which no longer existed. Recreating security in Vault using groups is probably a good idea for easier management.

3) Fill the import machine with memory. Large imports are memory-hungry. Just one project in our database needed over a gig of RAM to import.

4) Use the fastest processor and memory possible. The import pre-scan seems to only use one CPU, so make it a good one

5) Import from a copy of the database, having first deleted and purged anything you don't want to bring over. For some reason, you can't select more than one project to import at a time, which is a shame. [edit] An alternative solution is to move (not share) everything you want to import into a new project, then import this new project.

6) Run analyze -f -c. Run it again if it finds errors the first time. If possible, use VSS 2005's analyze -fp -s -c -v4, as it seems to find and fix more things.

7) Monitor the import log file during the pre-scan. If you see any errors, appearing, you may want to stop to investigate the errors rather than waiting hours or days only to find that the import doesn't work properly. tail.exe (comes with cygwin, but there are other stand-alone freebies out there) is good for real-time monitoring.

lbauer · Post by **lbauer** » Tue Nov 07, 2006 11:18 am

Thanks for the tips. I'm sure they'll be helpful to other users.

It's a good idea to monitor the logs. I wasted a weekend on an import that appear to be running fine. When I reviewed the logs, I found the Vault server log reported a SQL timeout 7 hours into the import and after that, nothing was committed, even though the Vault Import Tool was plugging away. The import log showed commit failures, too.

I was able to restart IIS, which restarted the Vault server and the import started uploading files again. But by then too many files had been skipped because of upload failures.

bwhite · Post by **bwhite** » Mon Nov 13, 2006 6:52 pm

OK, I think I have everything I need to start importing, except that I can't see how to export projects from VSS.
Google returns a tool that exports only metadata.
VSS Help doesn't admit to knowing anything about exporting.

I don't want to import this whole thing at once. Definitely need to be broken up. What's the trick?

BTW, extra thanks for the help since VSS isn't even your software.
Brad.

GregM · Post by **GregM** » Mon Nov 13, 2006 8:03 pm

VSS calls it archiving and restoring, it is done through the VSS Admin program.

sswanson · Post by **sswanson** » Tue Nov 14, 2006 10:29 am

Forgive me for perhaps asking a stupid question...but how exactly does one go from VSS 6.0d to 6.0c?

lbauer · Post by **lbauer** » Tue Nov 14, 2006 3:22 pm

Download the contents of this archive:
http://download.sourcegear.com/files/vss_60c_hotfix.zip

Then replace the contents of the VSS 6.0d win32 directory with the contents of the archive. The key element to replace is the SourceSafe Automation Component -- ssapi.dll. The VSS Import Tool communicates with the VSS database through this automation component, so the version makes a difference.

grant · Post by **grant** » Thu Jun 21, 2007 11:40 pm

lbauer wrote: replace the contents of the VSS 6.0d win32 directory with the contents of the archive. The key element to replace is the SourceSafe Automation Component -- ssapi.dll.

Hi, I downloaded the zip. Inside it, there was a bunch of files, and a subdirectory called "hotfix". Inside the "hotfix" subdirectory, there was no ssapi.dll, which you have said is the important file.

So one more time please. What to do with the zip file contents? Is the "hotfix" subdirectory a red herring, or does the stuff in there go over top afterwards?

If the "hotfix" subdirectory is not needed, how about removing it from the zip file. If the ssadmin.exe and ssexp.exe in the hotfix subdirectory are supposed to go over the top, how about just doing that before zipping it up? and again removing the "hotfix" subdirectory.

Thanks,

jfuex · Post by **jfuex** » Thu Feb 28, 2008 3:12 pm

I had to selectively import about a dozen projects out of a larger sourcesafe repository. Each time I had to go through a bunch of prompts to get back to the import screen. Either a multi select or at the very least a prompt after each import to allow you to select another folder to import with the same settings would have made this go a lot faster.

mbblum · Post by **mbblum** » Fri Apr 04, 2008 11:05 am

Now that the solutions/projects are imported from VSS, how are the source control (SCC) bindings changed and updated to Fortress/Vault?

In VS2005 removing the SCC bindings and setting the SCC to Fortress/Vault is simple. Then "Add Solution to Fortress" is available. But it wants to add new entries in the database, not update the existing directories and files that were Imported.

If this has been documented somewhere or in the forums, please provide a link. My searches have not found this specific information.

UPDATE: Answer is not to "Add", but after changing SCC to Fortress/Vault return to the bindings and also set them to Fortress/Vault. Go to File -> Fortress Source Control -> Change Fortress Bindings. Set the bindings and it will checkout/checkin to the VSS Import.

Hope this helps others.

SourceGear Support

Tips for a successful VSS Import

Visual Source Safe 8.0

Import Tool throws exception

importing VSS

Suggested change to VSS Import tool

Change solution/project from VSS to Vault after import