Tips for a successful VSS Import

GregM · Post by **GregM** » Fri Aug 20, 2004 12:44 pm

Number 1 is the recommended option.

Post by **jeremy_sg** » Fri Aug 20, 2004 2:19 pm

Ben,

Option 1 is your best and safest bet. After the import is complete, you'll need to manually move over any changes that your developers checked in to VSS while you were doing the import.

bks · Post by **bks** » Fri Aug 20, 2004 2:21 pm

thank you for your response.

One more question, will the restore also restore the users? Or do I have to create them again in the VSS?

Thanks

Ben

Post by **jeremy_sg** » Mon Aug 23, 2004 7:49 am

I don't think that restore will recreate the VSS users, but the Import tool creates the users based on the history in the VSS DB, not the userlist in the VSS DB. Short answer: no, but I think that you will be fine importing a restored VSS DB.

dl2 · Post by **dl2** » Sun Nov 07, 2004 11:01 pm

We have a 7GB db that looks like it will take 5 days to import. We'd rather not stall our teams for that long. I was thinking of importing 1/5th of our root projects at a time overnight., but was wondering if a file shared between two different import sessions/sections would still be shared on the final Vault db ?

Thanks!

Post by **jeremy_sg** » Mon Nov 08, 2004 9:17 am

No, it won't recreate any of the shares between sessions. If you don't have that many, you could manually reestablish the shares like this.

Assuming that you had already imported

Code: Select all

$/FirstImport/file
$/SecondImport/file

If you delete $/SecondImport/file, you should be able to share $/FirstImport/file over to $/SecondImport without any problems.

If you have lots of shared files, email me and I will provide you with an import version that may be lots faster for you.

eft2e · Post by **eft2e** » Wed Nov 10, 2004 3:08 pm

Is there anyway of archiving a just a range of dates? Seems like the ssarc.exe only works on dates/versions OLDER than the one specified?

What I'd like to do is just grab the last 2 years worth of data to import into Vault. Same with the labels. Anyway of telling VaultImport to only use the labels that have been applied in the last X months ?

As a workaround to the first query, can I archive all the ones that I don't want, specifying delete from the VSS DB. But if I have a file in a project that is required for compilation but hasn't been touched in 5 years, will that be deleted too? or will it leave just the last revision for me even if it was 5 years ago?

Thanks!

Post by **jeremy_sg** » Wed Nov 10, 2004 3:23 pm

Unfortunately, I'm not going to be able to answer everything.

1. The Import Tool doesn't currently have the ability to ignore old history. But that would be great if it did. I've put that in the bug database, and we'll investigate to see if it's possible in the Import Tool. Thanks for the wonderful feature idea.

2. Can ssarc archive a range of dates and leave you with a much smaller database? I don't know.

S Malloy · Post by **S Malloy** » Wed Mar 09, 2005 11:21 pm

Where do you get a copyof 6.0c binaries?

I only have 6.0 or 6.0d

lbauer · Post by **lbauer** » Thu Mar 10, 2005 8:54 am

You can download 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.

S Malloy · Post by **S Malloy** » Thu Mar 10, 2005 5:34 pm

Ahh I see, the file contains all the required binaries.

Thankyou!

Our 92gb (Yes, Gigabyte) SS database is groaning. Hopefully the trial of SourceGear goes well.

lbauer · Post by **lbauer** » Fri Mar 11, 2005 9:05 am

S Malloy wrote: Our 92gb (Yes, Gigabyte) SS database is groaning. Hopefully the trial of SourceGear goes well.

That's pretty big for VSS!

A suggestion: you might want to split the VSS database up into different repositories in Vault.

Vault can handle a 92GB database, but if you have many thousands of files and and thousands of nodes, performance for concurrent operations will be improved if discrete projects are in their own repositories.

Post by **jeremy_sg** » Fri Mar 11, 2005 9:18 am

Also, you would be better off if you split your VSS database into smaller chunks and import them separately. To set your expectations appropriately, we've never tested such a large repository, and the import time for all 92 gigs would be in the range of a month. You should use this opportunity to choose exactly which projects are imported over and which aren't Another recommendation would be to import some projects with full history and some with only the latest version (by doing a get in VSS and an add in Vault).

S Malloy · Post by **S Malloy** » Sat Mar 12, 2005 4:42 pm

Yeah th eonly way I can import it is to break it into smaller projects.

Right now i'm in an evaluation phase, to prove that we can upgrade our important stuff to vault with minimum downtime/effort/cost

The decision to move to vault is all but made. Right now I have a 10gb import export running, I'll start the import process over Monday (which is a public holiday), and hopefully Tuesday have an important part of our sourcetree moved across with full history.

My intention is to sit down with the teams who will be using it, and go through a list of our subprojects and make the decision on which ones need full history, which ones can have just the head imported, and which ones can be archived completely, and never upgraded

Basically I just need to prove that the upgrade will work with one of our largish projects. In progress right now.

vaultuser2 · Post by **vaultuser2** » Tue Oct 11, 2005 2:04 pm

The last post on this thread was before version 3 of Vault was released. Is there any news regarding VSS 6.0d's compatibility with the latest version of Vault (3.1.2)?

SourceGear Support

Tips for a successful VSS Import

Shared Files on Multiple Imports

Archiving a range