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 verypoor 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.

If anyone has a concern about SubVersion being solely a source control tool, they should definitely look at Trac which can be configured with very tight integration with SubVersion.

Trac and SubVersion work well as a combination source control and lightweight project management tool. Trac allows you to view source code changes together with work tickets and wiki updates. It also supports such features as auto closing of Trac work tickets from within the comments of a SubVersion commit when you have the correct scripts hooked up.

However, I will say that Trac is definitely a programmer's view of a project management system. TFS provides the more heavy duty project management required in a an enterprise.

Not even one mention to Git?? There's something wrong here. I'm pretty sure it will take some time to make it hit the top of the list, but I'm sure it will be there, specially with visual tools like tortoise git and msysgit.

Excellent summary, Mike! We switched to Subversion at Madgex last year and it's been a pretty good experience. We're using VisualSVN Server which provides Active Directory support for users and groups and is FREE (as in beer). We also use the VisualSVN client for VS integration which is a solid tool and reasonably priced. It takes the approach of doing just enough for VS integration and leaving the rest to Tortoise. Less is more.

To the previous commentator, if you look closely, Git doesn't offer many advantages to a shop with permanent, co-located devs. If you're team isn't distributed, distributed SCM doesn't offer a whole lot, especially when the tools are so immature.

I am wondering about the difference between Subversion and TortoiseSVN.

My understanding is that TortioseSVN is a front end (client piece) to Subversion (server piece). If you go to the TortoiseSVN page and download it, does it come with the Subversion engine or do you have to get both client and server pieces separately?

You are correct. TortoiseSVN is a Subversion client. If you need to host your own Subversion server, you will need to install it separately. However, I'd really recommend looking at cloud based Subversion hosting, it will relieve you of the hassle of maintaining and backing up your own server instance.

Code Rant

Notepad, thoughts out loud, learning in public, misunderstandings, mistakes. undiluted opinions. I'm Mike Hadlow, an itinerant developer. I live (and try to work in) Brighton on the south coast of England. Please don't mistake me for an expert in anything. I love technology and programming, but make no claims to be any good at it. Much of what you read here may be poorly thought out, wrong, or just plain dangerous.