SourceGear Support

What does the network look like between your IIS server and the SQL server? Some kind of communication loss between them is the only thing I can think of that would explain this error.

Obliterate is transactional. So when it timed out everything would have been rolled back. Obliterate effectively has no SQL command timeout, so network connectivity between the web server and the database server must have been (at least momentarily) lost, or SQL Server was stopped/restarted. Do you ...

Mike,

Thanks for that feedback. Obliterate will continue to be improved for the 4.0 release, and this type of information is very useful.

The VSS import imports lots of temporary data in order to preserve the labels. If you have a large number of labels in SourceSafe, and you import them all, there will be a large number of deleted items when you're done. It sounds like you have a very large number of these. The behavior of the oblite...

Good point. I have removed it to be consistent. :oops: I probably didn't explain sufficiently in that thread that this is more of a last-ditch step than a good idea for casual use. The situation in the other thread was different in several important ways. Vault was effectively non-functional due to ...

This is definitely not safe. Don't do this. The primary reason it's faster is also the primary reason it's dangerous: there's no SQL transaction. If the obliterate can't complete for any reason (like a branch conflict), you'll be leaving your repository in a half-baked state. There are a few other, ...

Without a backup prior to the import that added 65 GB, there's no good way to keep the history you've got in Vault now, I'm sorry to say.

Importing just 5 labels should be reasonable.

Is there data (particularly history) that you care about in Vault that is not in SourceSafe? If not, I'd recommend re-installing the Vault server, choosing to remove the existing database. Before trying again with an import, it may be helpful to review this (if you haven't already) to help ensure a ...

While that feature is slated for the Vault 4.0 release, there is unfortunately no way to archive/restore arbitrary folders in a Vault repository today.

Do you happen to have a backup of Vault's database before the VSS import?

Unfortunately, with 65 GB of data to delete from a VSS import, this isn't terribly surprising. Obliterate is still slower than we'd like. Is there data that you care about in this Vault database, or was this an import into a fresh installation? It would be far easier to simply re-install vault and g...

With @reallyobliterate=0, you should have no trouble using the system other than a perceptible slowness while it's running.

With @reallyobliterate=1, running directly from SQL as you are, you would be safest letting the obliterate finish before using the repository.

At this point I'd recommend that you attempt the obliterate right on the SQL Server. Near the beginning of the profile you were running, you should see a call to the stored procedure that performs the obliterate. Something like this: <snip> Note from Ian: this script is not "safe" under al...

You're right. I've logged the bug.

Well I wasn't sure how long you waited. It certainly shouldn't take hours to populate that list unless you've got some really extraordinary circumstances. You'll probably be able to do what you need to do using the command-line client, but if you do find that the Admin Client is flashing indefinitel...

Yep, "vault help" will give you a list of cool things to do. :) With respect to the flashing on the obliterate tab, the list does appear to be flashing while it is being filled on some systems. It's possible that you have a very large number of deleted items, and that the list is still bei...