The one simple answer to choosing a source control tool is easy: don’t choose SourceSafe.
It has many issues including:
- Commits are not atomic. If a file is changed you have no way of linking a set of file changes that implement a particular feature or fix a bug.
- Lacks usable branching support.
- It doesn’t keep a history of file renames. If you rename a file and than get a version previous to the rename, the file will have the new name.
- Permanently deleting a file also deletes its history. This means that versions of the software prior to the deletion are not valid.
- Requires a file share to work and does not perform well over slow connections.
- Randomly corrupts its own database.
- Many other issues, detailed here.
The first point pretty much rules out Source Safe if you want to do continuous integration. Without atomic commits your automated build has no way of knowing when a related set of changes has finished arriving. I’ve seen kludges where the build server waits an interval after the last check-in before kicking off a build, but they are just that; kludges.
Source Safe has historically been the default choice for Microsoft shops. If it’s so bad, what should we be using instead?
There are many source control systems on the market, but I think the choice fundamentally comes down to two contenders: Microsoft’s recommended tool and the most popular tool.
Microsoft recommends the source control system from Team Foundation Server. I’ve been using TFS source control for over a year. Admittedly I haven’t exercised features such as shelving or branching, but my experience has been good.
However TFS is much more than just a source control tool, and unfortunately some of the other features are not good examples of their type. The unit testing tool in particular is very poor and the build server is unnecessarily complex and hard to use. The integration with Visual Studio is too intrusive; it’s hard to work disconnected and you can only be connected to one TFS server at a time, which is a serious limitation.
I haven’t used the integrated bug/task tracking, but that might be a good reason to favour TFS over competing SC tools. If you know you need TFS for its tight integration and management tools, then I think you can be pretty confident about its source control capabilities.
Subversion is the most popular source control tool for a reason; it is robust, mature and has a vibrant supporting tools market, including the excellent windows client, tortoise svn. It has been very successful in the open-source world and powers several huge on-line source repositories, including Source Forge and Google Code.
Its main weakness, when compared to TFS, is that it is only a source control tool and doesn’t come with an integrated build server, test and management tools. You can put together your own suite from commercial and open source suppliers, but their choice and integration is up to you. However, because of Subversion’s popularity, integration points for it are well supplied.
Integrating Subversion authentication with Active Directory can also be tricky, something that is much easier to do with TFS. If you want to integrate easily with your existing developer list, that might be a reason to choose TFS over Subversion. A guide to using Subversion with LDAP can found here. Altassian provide a product called Crowd that can apparently be used for integrating LDAP, but I haven’t had any experience with it.
If tight integration, especially of management tools, is not a priority, it’s hard to argue against Subversion. For that reason I would favour Subversion as the source control tool of choice for most Microsoft shops.