I am trying to test the import tool with the demo version of Vault. I need ti import one of largest and most important databases, which is also still active; thus, I need to do it after hours. Unfortunately, the pre-import part takes several hours (at least - it was done when I came in the morning anyway) - by the time it is done, I have long gone home. The next morning, I cannot start importing because we are working in the database again.
Is there a way to tell the tool to just go ahead and start importing after the initial scan? E.g. so I can kick it off Friday at 5 and it will be done when I get in on Monday?
Thanks-
Luther
"Quiet" mode?
Moderator: SourceGear
-
- Posts: 56
- Joined: Wed Apr 28, 2004 3:28 pm
- Location: San Francisco, CA
- Contact:
I did a test import before buying Vault (haven't done the real import yet, still setting up hardware). I followed both of these suggestions from the Tips thread:
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.
I did an archive of the source I wanted to import, then restored that into a fresh database on the machine that was going to be running the import.
This also allowed me to do some cleanup. I purged all deleted items from the copied database. I also didn't import any labels. We're keeping the VSS database around for archival purposes, so we don't need those labels (this will become our second VSS archive, we have another one from just before a major re-org).
This way you can continue the import if it doesn't get through the first stage before you have to leave.
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.
I did an archive of the source I wanted to import, then restored that into a fresh database on the machine that was going to be running the import.
This also allowed me to do some cleanup. I purged all deleted items from the copied database. I also didn't import any labels. We're keeping the VSS database around for archival purposes, so we don't need those labels (this will become our second VSS archive, we have another one from just before a major re-org).
This way you can continue the import if it doesn't get through the first stage before you have to leave.