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

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.