What are the hurdles and dangers when migrating from Visual SourceSafe to SVN?_问答_开发者

A client still uses Visual SourceSafe, but after showing the numerous dangers and deficiencies of VSS, they've decided to migrate from VSS to SVN Subversion.

The choice-to-be seems Tortoise SVN with AnkhSVN (good choice?). A migration aid is described here. The project contains two websites, a few web applications, several control and function libraries.

It seems to me that a "sweep all VSS related" and then "import in SVN" is the way to go. But worlds aren't perfect. What are the problems we should watch out for and what measures can we take to have this process run smoothly? Are there typical SVN for .NET issues that we should be aware of?

开发者_运维问答

EDIT: is it possible somehow to migrate the VSS history too, or should we consider this a new start only?

We made the same migration a few years ago and were very pleased with the results. Like Pino, I recommend Tortoise SVN. AnkhSVN didn't seem to do work well for us. I don't know of a practical way of migrating the history.

The major problems we encountered were due to the nature of Subversion itself and not with the migration. The problems we encountered were:

Learning to work with merging and not exclusive checkouts.
Learning that nothing is ever deleted in Subversion. So adding your installer with prerequisites and then deleting it will not reduce the size of the repository. Our current backup size is 4GB+ compressed.
Backups require a bit of scripting, unlike SourceSafe which was a simple file copy. svnadmin hotcopy worked for us.
We found that 'user branches' where each user has a different branch did not work for us. We now have a single trunk for all users.
It was possible to commit a change without a comment. You can fix this with a pre-commit hook.
Giving up on MS Visual Studio integration. Not as bad as it sounds.

There are several tools that can migrate history for you. We used VSS2SVN a few years ago to make this same step.

You can use multiple subversion clients side by side. Almost every Windows user of Subversion I know uses TortoiseSVN and for integration in Visual Studio you can use AnkhSVN (Free, full SCC provider for VS 2005+ since AnkhSVN 2.0) and VisualSVN (Commercial; Uses TortoiseSVN with its own extensions and provides SCC-like features in VS 2003+).

I would recommend also installing a normal commandline SVN install for use by scripts.

See AnkhSVN vs VisualSVN for more comparisons between VisualSVN and AnkhSVN. But note that all the clients (TortoiseSVN, AnkhSVN, VisualSVN) are just a shell over the same libraries, so you can switch between them any time you like.

By far the biggest hurdle will be educating the developers to the differences in using the source control systems.

Checkout Edit Checkin to Edit Merge Commit:

Developers new to SVN have to be comfortable with the idea of two developers making changes to a file at the same time, and that they will merge those changes later. VSS users are typically unaware that this style of source control is even possible and most certainly don't feel comfortable with the transition.

Project Binding to File System Binding:

VSS typically manages source control at the project and solution level. The project is bound to the source control and any changes which happen to the project also happen to the source control. In SVN, there is no such binding. All changes are tracked at the file system, meaning that when you add a new file to your project, you also have to add the file to the source control.

For this reason alone, I recommend investing the time to set up a continuous integration server for your projects. This will quickly pick up on any files which are missed from commits and prevents the awkward scenario of other developers doing a checkout and getting build errors because a file is referenced in your project, but is not present in your source control.

Branching:

Although you can perform branching in VSS, I've rarely seen anybody use it because it's quite tricky to set up a branch, switch to a branch and then merge the branch when you're finished with it. Branching isn't required to use SVN, but it's probably one of the big reasons you'd make the switch. Developers need to get comfortable with the idea of creating branches where it seems appropriate and re-merging them into the Trunk.

If your developers are already comfortable with using SVN, you shouldn't have any problems. If not, they may need a bit of guidance to make them see the advantages of SVN for themselves, and hopefully end up enjoying using it.

Number one bit of advice: Keep a backup :) Number two: Tortoise SVN - Defo the way to go for a windows machine, plus integrates with Visual Studio (Via VisualSVN)