There is currently no direct migration recipe for VSS repositories. The suggested approach is to:
- vss2svn processes the backend VSS database and does not require VSS itself
- Most of the other solutions require the VSS program
Most of the solutions require the Visual SourceSafe “SS.exe” program to operate, except vss2svn. There is a COM API for VSS but it doesn’t expose all the features, so dependent tools parse the output of SS.exe. Even SS.exe doesn’t allow you to retrieve all the data, as you can’t retrieve deleted or renamed files, so vss2svn would seem to be the most thorough solution.
As it processes the backend database, vss2svn would be the best candidate for porting to a vss-fast-export, but bear in mind that most of these projects are very mature ; vss2svn seems to be the most active and the source hasn’t been touched in a year.
All the solutions seem to suffer from locale issues. The output of SS.exe is localized. All utils suffer from the fact that VSS uses the path encoding of the client, so paths can have a mixture of encodings.
Home