CODEWITHSUNDEEP
svnversion-controlvisual-sourcesafe
sgwill
sgwill

Reputation: 10524

Best way to migrate from VSS to Subversion?

I'm a single developer looking to get off of Visual Source Safe and move to svn.

A quick search brings up several tools, but I don't see a clear winner and I can't afford to spend a lot of time testing different tools.

Has anyone done this successfully, and can recommend a method?

Upvotes: 25

Views: 20268

Answers (10)

Eric Schneider
Eric Schneider

Reputation: 61

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.

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

Eric.

Upvotes: 6

Hakuna
Hakuna

Reputation: 21

The following tool works quite well: http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration

It takes a bit of work to clean up the imported repository, but if you really want to keep your history it could be worth it.

Edit: pumacode.org domain is gone, the code is now hosted on https://github.com/irontoby/vss2svn

Upvotes: 2

Bruce Grissom
Bruce Grissom

Reputation: 19

I have used vss2svn with great success.

Upvotes: 1

JoelHess
JoelHess

Reputation: 1207

The CodePlex Version of VSStoSVN is one of the best I've found. I had pretty bad results with the PumaCode version, but this one ran smooth.

http://vss2svn.codeplex.com/

Upvotes: 8

fglez
fglez

Reputation: 8552

We downloaded and tested several migration tools and I would recommend Polarion SVNImporter.

We used it to carry a selective migration of almost a Gb from a VSS6 repository to Subversion. As the source code is available, we were able to patch it and tailor to our specific needs (linked files detection).

Upvotes: 1

Jon Galloway
Jon Galloway

Reputation: 53115

I recommend just adding your code to a new Subversion repository rather than importing from VSS. VSS has a convoluted version control model that doesn't translate well to many other systems, and just starting fresh is usually the best way to avoid taking that clutter with you.

If you need to keep the history around, make your VSS repository read-only.

Upvotes: 28

Caroline Orr
Caroline Orr

Reputation: 796

I totally agree with Jon Galloway's answer. I have also tried using vss2svn but found that there were a lot of problems with the imported repository and in the end decided that it was not worth the effort required to clean it up. We just imported a copy of the code into subversion and have gone back to VSS on the rare occasion that an older version of the code needed to be consulted.

In my previous company we also used the same approach for migrating from ClearCase to Subversion, and I can't remember any occasion that we ever needed to go back into ClearCase to look at the history.

The biggest issue was getting everyone to switch to the new repository at the same time, but as a single developer you shouldn't have any problem there!

Upvotes: 1

Jim T
Jim T

Reputation: 12416

We did this migration recently at work. I strongly suggest:

  1. Just add the new code from VSS, take the hit that pre-svn history will have to stay in the old VSS repository.
  2. If your VSS repository is still in use after the initial code dump, migrate changes using Vendor Branches. Ie, assume your VSS repository is a vendor and use dated tags to merge the changes into the SVN repository.

Slightly more detail here.

Upvotes: 7

Ethan Gunderson
Ethan Gunderson

Reputation: 11507

At my current job we just created a subversion repository, setup hook scripts to ignore all vss and generated files, and then just started importing the various projects with tortoiseSVN. Worked out pretty decent, we were up and running within a couple of hours.

Upvotes: 1

Greg Hewgill
Greg Hewgill

Reputation: 993015

I have used some script (I can't remember which one) to assist in a VSS to SVN conversion. It was a bit painful and finicky but ended up working, and kept all history. I had to keep all the history for political reasons at the time; if I had my way I probably would have thrown away the history and imported all the code into SVN.

Also for political reasons, I wrote some really hacky scripts that kept VSS updated with changes from Subversion. These worked for a while but kept breaking every week or two, until somebody renamed a directory or something and the whole thing fell apart. By that time it was okay to simply continue using Subversion.

Upvotes: 0

Related Questions