Don't Use Microsoft Visual SourceSafe!

Let me summarize this simply as: Don't use Microsoft Visual SourceSafe if you are starting a new Microsoft/.NET project and you have the choice of considering other version control systems. Or if you're finding that SourceSafe is not scaling well for your team and you are looking for cost effective alternatives. Use the Subversion version control system instead, which is open source. Since Subversion doesn't come with a friendly graphical client tool, install this great open source client tool that integrates into Windows Explorer, TortoiseSVN. TortoiseSVN also provides a good built in diff tool, but there's an even better one called WinMerge. It's easy to install WinMerge and it will integrate itself into TortoiseSVN.

If you need web access for your source code, Subversion gives you that. You will need the Apache web server. You can install either Subversion or Apache first. Just be sure to follow the Apache WebDAV setup directions in the Subversion documentation.

You can install all of these things on Microsoft Windows in case that's the only platform that you have available.

You will find that your development team will be more productive with Subversion. You also won't be constrained by a poorly performing version control tool, and you'll have the flexibility of working in the office or at home, and working in a distributed environment, and you'll have a better set of tools.

If you've had experience developing with Visual Studio .NET and Visual SourceSafe, you may have used the "Source Safe Plug In" that installs into Visual Studio .NET. It's a handy little plug in when working with SourceSafe because of how it allows you to start modifying source code right away. You don't have to explicitly "check out" files when using the SourceSafe plug in.

With Subversion, you don't need this type of plug in. The reason that you don't is because of Subversion's "copy-modify-merge" approach to version control. Visual SourceSafe uses a Lock-Modify-Unlock approach which truly necessitates the use of a plug-in for more developer efficiency. So with Subversion all you wind up needing is just an external client like TortoiseSVN. It might sound counter-intuitive to not require a plug-in within Visual Studio .NET. You just have to try it out to really understand why if you're not yet familiar with the copy-modify-merge approach.

There is a Visual Studio plug in for Subversion available regardless called AnkhSVN. It is an option that can save you a little bit of time, but in practice I've found that it doesn't scale well with very large solutions due to its implementation limitations. In one 10,000 or so file solution that I have, AnkhSVN was taking around 5 - 6 minutes at a time to synchronize with Subversion. And AnkhSVN synchronizes often enough that it is a performance issue. I don't have that kind of time to spare. In smaller solutions it works better. But even so I still prefer TortoiseSVN.

Finally, if you're responsible for your entire development team's version control platform, and you're considering Microsoft's extremely costly and not very mature Team Foundation Server, let me be the nay-sayer to this and recommend going the open source way at least for now. You'll get best of breed options and you can easily set up other best of breed open source solutions for unit and integration testing, bug tracking, etc. And you'll save a ton of money. Stick with a cheaper version of Microsoft Visual Studio .NET.