RE: VSS Import Errors

I'm sorry you're having so much trouble with
the import tool.

Our first step in helping resolve any problem
with the import tool is to make sure you've
read the following tips.   

If you've followed the instructions below and
are still having problems, we are of course 
available to work with you and get it figured
out.  This list of tips is just a starting point.

We're trying to make sure people get this 
document and read it *before* they lose 9 hours 
of their life, but we're not quite there yet.  :-(

----

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

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q323917

    The hotfix is also available at

http://www.sourcegear.com/vault/downloads/vss_60c_hotfix.zip

    Do not use SourceSafe 6.0d.

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.

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.

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

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

12.  Note that in Vault 1.1, importing labels can be
     extremely slow.  You may wish to import only
     those labels which you actually need.  This
     suggestion does not apply to Vault 2.0.

--
Eric Sink
Software Craftsman
http://software.ericsink.com/

 
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Matt White
Sent: Tuesday, December 16, 2003 5:32 PM
To: [email protected]
Subject: [vault-list] VSS Import Errors

I posted a long rant last night which never made an appearance on the list
cos it exceeded the 60K limit.....
 
Anyway, after 9 hours processing last night, I can happily say that
everything failed to import, so I was left with an empty Vault repository
and nine hours of my life I'll never get back....
 
But having trolled the log file (can you keep display and error/success
count on the VSS import form? Would have saved me a lot of time last night)
that the importer creates, there is the same error over an over again... :
 
Beginning Export.
Begin Export....
 
Memory used: 35872768.
Created  ($/Redgum/Testing) at 4/2/2001 1:30:10 PM
Change set type: CreateFolder
Adding to transaction: $/Redgum/Testing - $/Testing
Server unavailable for transaction end
Transaction failed
Transaction failed
**Failed** - Error trying to commit. Exception of type System.Exception was
thrown.
Trace:   at VSSImport.WizardForm.a(String A_0, DateTime A_1, Int32 A_2)
12/17/2003 10:18:47 AM - Unable to commit for 4/2/2001 1:30:10 PM -
$/Redgum/Testing - Created .
Refreshing SourceSafe connection...
Opening: D:\SourceSafeData\Redgum\srcsafe.ini
User: admin
VSS database open: True
 
12/17/2003 10:18:47 AM - Refreshing connection to the Vault server.
 
Logged out of the Vault Server.
Connected to Vault.
Server unavailable for transaction end
Transaction failed
Transaction failed
**Failed** - Error trying to commit. Exception of type System.Exception was
thrown.
Trace:   at VSSImport.WizardForm.a(String A_0, DateTime A_1, Int32 A_2)
12/17/2003 10:19:18 AM - Unable to commit for 4/2/2001 1:30:10 PM -
$/Redgum/Testing - Created .
Refreshing SourceSafe connection...
Opening: D:\SourceSafeData\Redgum\srcsafe.ini
User: admin
VSS database open: True
 
 
etc, etc......
 
Vault itself seems to be running OK - the Client and Admin tools both
connect OK... the SQL database is online and accessible. 
 
The machine being used for the upsize is a 1.1Ghz Celeron, 1Gb RAM, Windows
2K fully serviced packed and freshly built from scratch yesterday. Only
applications installed on the machine are VB6 Enterprise, VSS 6.0c, Vault
Server, Vault Client and Vault VSS Import Tool, SQL Server. Destination
database is MSDE SP3, again freshly installed yesterday. Only database
attached (apart from the default 4) is the Vault DB. Everything else is
local, VSS Database, IIS, SQL Server, the works. 
 
I'm using the SUE edition (for the import only - once I'm happy with the
import, I'll roll out the dev licences I need), so I don't know if the
problems are related to the restricted user count - there are about 10 users
(past and present in the VSS database, of which 5 were active in the VSS
project branch I'm importing) or what.
 
Any ideas?
 
Matt
 
____________________________________________
Matt White
Software Engineer [email protected]
<mailto:[email protected]>  Advanced Publishing Systems Pty Ltd
Phone: (03) 9940 1441 Fax: (03) 9940 1458 
	
420 Victoria Street
Brunswick VIC 3056