How do I convince my team to drop sourcesafe and move to SVN? [closed]

Question

Reliability

• SVN is a lot more reliable with large databases
• SVN is still actively supported
• Atomic commit - in VSS when you get latest version while another user is performing checkin, you can get an inconsistent state, forcing you to repeat the "Get latest version" in better case, but sometimes when unlucky you may be left with a codebase which compiles but does not work. This cannot happen in SVN thanks to atomic commits.

Features

• SVN branch/merge is a lot better
• SVN has builtin support for remote access
• SVN is more configurable (integration of external Diff/Merge tools)
• SVN is more extensible (hooks)

Better productivity

• SVN "Update" is a lot faster compared to SS "Get latest version"
• SVN command line is a lot easier and cleaner - this is useful for automated build or testing tools

Same level of IDE Integration

• VSS had a lot better VS integration until recently, but with AnkhSVN 2.0 this is no longer true.

Open

SVN is open and there is plenty of various tools using SVN or cooperating with it. Some examples include:

• integration with many bug tracker or product cycle management products
• shell integration
• integration into various products
• various management and analysis tools
• source is available, you can adjust it to your need, fix the problems (or hire someone to do it for you) should the need arise

Cost

• You do not have to pay any license or maintenance fees

First, teach them how to use SourceSafe in an efficient way.

If they are smart enough, they will begin to love the advantages of using a version-control system, and if so, they will soon reach the limits of SourceSafe. That's where they will be the more able to listen to your arguments for switching to a better VCS, could it be a CVCS or a DVCS, depending on what's the team is ready to achieve.

If you try to force them to use another VCS when they use SourceSafe in a wrong way, like saving zip file of source code (don't laugh, that's how they were acting in my company two years ago), they will be completly reluctant to any argumentation, as good as it could be.

Find some excuse to start using non-ASCII characters in your C# code (Chinese and Japanese are excellent for this).

SourceSafe doesn't like Unicode (even though Visual Studio does), so if you choose the right Unicode text and check a file in and back out, your entire file will appear as corrupted gibberish. The beauty of this is that because SS uses a "diff" versioning system, this actually corrupts the file all the way back to the original check-in version, and can't be fixed automatically.

When this happens just one time (as it did to me when working on an application that had to support Japanese), you will probably find it to be a decisive argument in favor of dropping SourceSafe.

There were two features that we used to sell management and the team on SVN over VSS.

1) The ability to branch. When using VSS, when a release was scheduled to go out, the entire repository was locked until the release actually went out. This included the test and fix cycle. So, developers were unable to commit anything other than fixes for the release to the VSS repository. This resulted in long integration sessions immediately following each release. With the use of release branches in SVN, there is no longer any need to lock the entire repository.

2) The ability to rollback an entire change at once. Because SVN records all files changed in a single, atomic commit, it is trivial to revert a problematic change. In VSS, a developer had to go through the entire repository and find every file changed at about the same time and revert each change to each file individually. With SVN, this is as trivial as finding the relevant commit and hitting the "Revert Changes from this Commit" button in TortoiseSVN.

As a side note, we use TortoiseSVN and everyone loves the file overlay icons for seeing what has and has not changed.

Whatever you do, move slowly! Don't start talking to them about branching on Day 1 -- it will just put them off. I'm stereotyping VSS users with that comment, but that's what I see out there.

For the developers: sell it as a replacement for VSS that works better and faster. Use VisualSVN on Day 1 so they have a super-shallow learning curve. Sell them on it being the same except faster, more stable, and 2 people can edit the same file and they won't have problems with some guy being off sick with locks on a bunch of files.

For the admins: sell them on it being more stable and easier to administer than VSS. Show them VisualSVN server.

Good luck!