Has anyone successfully migrated VSS 2005 over to SVN?

Question

I've been playing around with SVN for the last little while and have come to love its power and user experience and that we can tie it into our bug tracking system to simplify everyone's lives. So it's come to the time that we've decided to migrate our VSS 2005 setup across to SVN and I am now coming unstuck.

It seems there are a number of tools out there that claim to be able to complete the migration from VSS 2005 to SVN, but I can't figure out which is the best one or which will provide me with the most complete transition. I need one that will migrate the full history across rather than just checking out from VSS and checking into SVN.

I found Polarion SVN Importer which looks both powerful and highly configurable, however, I can't get the damn thing to work, it complains that it can't pull the file list from $/ in VSS. If I run the same command it's tripping up on manually, everything seems to run okay, so I can't figure it out.

Has anyone successfully migrated their source from VSS 2005 to SVN and if so what tools did you use and what were your findings? Any caveats or gotchas would be most useful so know as well as anything that was useful/surprising or was a let down or just plain misrepresented.

Answer 1

The last time I tried this was years ago. Because the VSS file format wasn't documented, to get a complete history the 3rd-party conversion program had to use VSS's API to get each version of each file. I let that conversion run over the week-end, saw how much it had accomplished (a few percent), and calculated that it would take weeks of calendar time to complete (we had years of history).

We therefore decided to move only a snapshot of the latest code into the new version control system, and kept an archive of the VSS database for history's sake.

Answer 2

Similar to this question - different migration, but I also think it is a waste of effort/time to try to capture the history.

http://stackoverflow.com/questions/868789/whats-the-best-way-to-migrate-from-sourcesafe-to-clearcase/868834#868834

Answer 3

I successfully migrated VSS 2005 to SVN several months ago. I used the "VssMigrate.Tim2" tool which is apparently on CodePlex now as vssmigrate. It worked fine with no major issues. It did seem like the revisions and timestamps weren't ordered quite like I expected, but it wasn't a big deal.

EDIT: With vssmigrate, you can choose to migrate a specific VSS path (e.g. $/GroupA/ProjectB) which reduces the time for individual migration and makes the overall process less fragile. I didn't find the process too long although we only had about six months of data in VSS. I managed to complete the migration and Apache+SVN setup over a weekend. Depending on the size of your VSS repository, you may want to create multiple SVN repositories instead of a massive single repository.

I am extremely glad we moved away from VSS, although configuring Apache+SVN wasn't too much fun (trial and error). I was considering Git or Mercurial, but neither had a reliable TortoiseXxx tool or VS SCC plugin at the time. Although now that Google code has supported Mercurial and TortoiseHg looks good, I'm tempted to try Mercurial soon.

Answer 4

I tried both Polarion and vss2svn about a year ago.

We had many years of code in VSS, and I found that after all of the configuration and testing that I was not entirely satisfied with the results, the process was long and fragile, and in the end, decided to just start with a clean import of the latest code.

There have been a few times over the last year where I went looking for old history, but not really that much. Another plus of starting fresh is that your new SVN repository will be very fast!

Answer 5

Try the lastest trunk (console app) revision for VssMigrate on Codeplex to re-order your history and re-generate changesets from your VSS repository. It will also order your revisions correctly based on the time they were checked in.

http vssmigrate.codeplex.com/SourceControl/changeset/view/16890

I hope this helps. It might take some tweaking on the $/ import.

P.S. the history helps you know who to blame in a single step rather than having to discover if the annotation is correct based on an import, so I find it rather useful. Much better to have it than not have it when finding bugs in older code.

P.P.S. You can even use the new version of VssMigrate to re-import the revisions to a subversion repository and then merge in all of the revisions after the last import revision from your previous revision. The only downside is that everybody will have to get a fresh check-out from the repository because the number of revisions will be dramatically reduced. Basically, perfom a new migration; svnadmin dump active previously migrated repository from rev migrated+1 as incremental and then svnadmin load into the newly migrated repository.