VSS Import Tool Slow and Problematic

[davenovak]

Speaking as someone who has used the Vault VSS Import tool quite a bit over the past several weeks, I speak from experience when I say:

• 1. It is slow and it could be made to be faster
  2. It is problematic with complex imports (especially databases that make extensive use of sharing and pinning)
  3. It is very restrictive as to what you can import

Please allow me to elaborate on each of these points.

• 1. slow and it could be made to be faster – Please let let me suggest a couple of possible user options:
  • Skip labels – if the person importing does not care about labels, they should be able to say this at the beginning (presuming that makes the pre-scan faster). Importing labels is so slow it’s just not worth trying.
  • Limit history – Allow options to limit history to either n versions of each file or by date. Many people only really care about the latest version, but want to preserve file shares. Certainly this would speed up the import process.
  
  2. problematic with complex imports – I’ve had some databases import fine without any errors and others fail miserably. Size didn’t seem to matter so much as to success or failure; rather the overall complexity made the difference. Those databases with lots of shares and branches and made use of pinning had the most problems. Some databases took literally days to import and then would at the end tell me that it failed with 1000+ errors. What’s most disturbing is that I have no problems pulling any version of the “problematic” files from SourceSafe I’m honestly not sure how I ever got finished, but I persisted.
  One repeated error I’ve seen (and reported) is:
  VaultServiceBase.VaultTreeException: Error in the application.
  at VaultServiceBase.VaultFolder.DeleteFolderEntryByName(HybridDictionary htParentObjects, String strSearchName, Int32 nObjType, Int32 nFSOHashCode)
  In some cases, I had to punt and do an Add files/folders from the Vault Client (at the expense of all history and file sharing).
  Bottom line: if I can get the files successfully from SourceSafe, then your import tool should not fail. I have done "do diligence" here by running analyze first and working with a machine local SS database, yet still I have problems. Your tool needs to be more robust in handling its own errors and any SourceSafe problems. I expect it to do the very best it can do.
  
  3. very restrictive as to what you can import – I mentioned this earlier in the non-gold forum (http://support.sourcegear.com/viewtopic ... highlight=), but it bears repeating: it would sure be nice to be able to import more than just 1 project. The current choices are the root project (or all project) or any other single project. Although I do have somewhat of a workaround for this (see mentioned post), this adds about a day to an already painfully slow process.

Despite all of this, I’m happy I managed to hang on during the conversion process and that importing is pretty much a 1-time deal. Day-to-day life with Vault is much happier.

[Beth]

Points taken on the VSS import. We do try to make this as painless as possible. I would highly encourage all users to plan ahead and to check out the articles on it ahead of time as the import is a very large task.

It is an option to only import the labels they need and importing only part of history. It's mentioned in the second article below.

Our KB articles on VSS importing are the following:
http://support.sourcegear.com/viewtopic.php?t=7
http://support.sourcegear.com/viewtopic.php?t=6949
http://support.sourcegear.com/viewtopic.php?t=3953

I think I added your last item as a feature request.

Either way, thanks for the feedback. This will help keep other users informed that this isn't something to be taken lightly.

[davenovak]

Most definitely users should read those articles first. I did and they helped.

As to labels, yes, importing labels is "optional", but the option for this comes up after the pre-scan. If the pre-scan (which itself is very time consuming) could go faster by skipping label history, then a new option to skip labels at the beginning of the import makes sense. This is what I was trying to say earlier.

For example, we had one project that we imported where the pre-scan alone took the better part of a day to complete. The reason? Turns out that the developers who managed that project had a “continuous integration” environment setup, which kicked off a build every time a file was checked in. Part of their build process included labeling the build. There we literally thousands of meaningless labels in this project history and each file took close to a minute to pre-scan. If that could have been avoided (since I don’t care about labels), that would have helped as pre-scan would have gone much faster. But perhaps there is no way in SourceSafe to differentiate between inherited label history and actual file change history. I hope this makes sense.

[Beth]

Makes sense and I'll add that as a feature request. Thanks for the feedback.