Question

Is there a way to migrate SourceSafe with HISTORY into a SVN ?

Ideally I'd like to use VisualSVN Server, but I don't really want to lose my SourceSafe history. If I have to I will though.

Was it helpful?

Solution

A long time ago (it seems) I tried to migrate a SourceSafe DB to subversion using vss2svn, but finally gave up. There were several problems, IIRC:

  • you have to make sure that the SS DB is consistent (e.g. Analyze does not find any problems or is able to fix them).
  • it took a very long time to migrate the DB, because it was quite big.
  • finally the migration failed due to some problems with parsing dates. I wasn't able to find the reason for the problem, but I guess it was due to the fact that we use DD.MM.YYY date format instead of US date format.

So finally we decided to keep the SourceSafe DB intact (read-only) and just migrate the current version into subversion. So far, there were very few occasions where we had to go back to SourceSafe to check something.

Hope this helps.

BTW: it does not matter whether you use VisualSVN Server or subversion directly (svnserver). The repository format is the same in both cases.

OTHER TIPS

Try the vss2svn script.

Or the vss2svn project.

I successfully converted our nasty VSS database including history. I blog about the experience here. The conversion highlight is:

"All of the conversion tools also required the source VSS database be clean of corruption before the conversion. This turned out to be much harder and time consuming than you might think. Running the VSS Analyze tool on a copy of the database showed hundreds of corruptions and would not run to completion without blue screening the computer it was running on.

To get around this we reduced the copy database by deleting the directories that we didn’t want to convert. Unfortunately VSS will report each corruptions during the deleting process causing hundreds of message boxes that the user must mindlessly click for the process to continue.

Once that point was reached, we used the tool VSS2SVN to create dump files that were imported into Subversion."

We used Polarion SVN Importer to migrate VSS to SVN with full history.

Yes, use the VSS2SVN project on Codeplex. I've updated it so it maintains history, comments, author and date properties when migrating to SVN. Takes a bit longer, but I don;t think that matters as its not something you do everyday.

It also has an option to update the repository with files from VSS past a certain date, so you can update an initial dump later on.

At my company I tried repeatedly to migrate a (big) SourceSafe repository to Subversion with vss2svn. I even caused a small contribution regarding codepage support (we had filenames in Greek). If I remember correctly (this happened last spring; i.e. of 2009), our main problem (the one that made us finally dismiss migration) was that permanently deleted files that were cross-linked/moved between wanted and unwanted parts of the repository were blocking the migration.

My suggestion: If you can't do it in a fully Analyzed repository, don't waste more time. Just draw a line and start with a new subversion repository.

Note: Permanently deleting a file in SourceSafe makes the file totally unrecoverable, which is something entirely incompatible with CVS/SVN-type source control systems (and, I suppose, other source control systems as well).

My company has developed a Source Safe to Subversion migration tool: http://www.abstrakti.com/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. Additionally, it's able to deal with most of SourceSafe repository corruptions, and offers a painless migration to users who don't want to spend a few days debugging into C# code.

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

Eric.

I successfully managed to migrate the several source safe repositories into SVN using vss2svn script. My suggestions are, do it in small chunks - we had a lot of little projects and a couple of medium side projects, which all managed to be moved successfully to SVN.

I had a couple of problems:

  • Big files failed to be written in to the SVN dump file format, I submitted a patch to make it work, I think someone wrote it a bit more sophisticatly after I was done.
  • The root directory structure was not copied across correctly. The VSS repository was organised as $/client/project. The svn repository ended up being organised as svn://server/randomdirectory/anotherrandomdirectory/client/project. So I fixed these by editing the dumpfile before importing it (I think it was find replace "/randomdirectory' with ''.
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top