Migrate a Source Safe database to SubVersion with

问题:

Folks,

We have a number of Source Safe databases that should be migrated to SubVersion. Is there a (tested and proven) way to migrate them with history ?

Thanks Essam

回答1:

You can try VssMigrate. It is a C# port of PowerAdmin's VssMigrate which has the capability to "Resolve the individual VSS-checkins to atomic SVN commits via the approximate timestamp".

回答2:

I'm considering the migration too and I have found some pages that may help you in the process:

• Moving from Visual SourceSafe to Subversion
• Vss2Svn Project page
• Migrating from SourceSafe to Subversion

This 3 pages provide information on methods to migrate the complete history from VSS to SVN

回答3:

Stumbled across this old question from a Google search. Another choice available is from Polarion who has a free SVN importer that can import from multiple sources. I'm trying it now...

http://www.polarion.com/products/svn/svn_importer.php

回答4:

My company has developed a Source Safe to Subversion migration tool: http://www.abstrakti.com/en-US/Products/Krepost

This tool was developed after having problems with every other tool, when we had to migrate a customer's repository. Also, this is the only tool that can import SourceSafe labels into SVN.

Let me know if you have any problems, I'll be glad to help you.

Eric.

回答5:

I would recommend the original vss2svn project (which I've used) compared to some of the other options listed here (e.g. VssMigrate) (which I have not used, but looked at the website) because it:

1. Runs on Linux where you get much faster file operations (compared to NTFS) (e.g. conversion runs in 30 minutes instead of 12 hours)
2. Is very hackable, generates intermediate, editable states (e.g. dump file)

In years past I used to admin VSS/CVS/SVN databases, and used vss2svn for a few VSS -> SVN migrations (in the order of a decade of history, 500MB, IIRC). My strongest caution to anybody converting a repository is that the biggest challenge is typically not how to map certain files to certain revision numbers, but how to gracefully handle corruption in the VSS database. This is why fast operation (you're not likely to achieve perfection the first time), and hackable operation are essential.

I would also highly recommend the vss2svn wiki pages on RunningTheMigration to anyone contemplating a migration, whatever tool you use in the end.