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.
The most popular source control tool, according to this survey is Subversion.
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.
Posts
12 comments:
For my hobby projects, where I am using Visual Studio Express (no plugins), I find Subversion works very well. Mainly because TortoiseSVN is such a good client.
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.
Some resources:
http://git-scm.org/
http://code.google.com/p/msysgit/
http://code.google.com/p/tortoisegit/
There are other, like Mercurial and Bazaar, but I'm pretty happy with git. No more centralized source control :)
+1 for git !
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 use TFS (With NUnit and CC), but would rather be using Subversion.
A lot of people I know rave on about GIT- it is one of the two being used at Google (the other is Subversion).
http://www.visualsvn.com/server/
No hassle & supports windows users.
Hi Mike,
Have you tried SVN-Monitor (http://www.svnmonitor.com)? I think is great to keep you in touch with the repository, specially when working with distributed teams.
Regards.
There's somet other things that Subversion is missing that TFS has: a $2800 server license fee and a $500 per workstation license fee.
Bruce, thanks for the VisualSVN Server tip.
Git looks like a fantastic tool if you are after distributed SC, I only hear good things about it. But for a team coming from VSS, I think SVN would be a better match.
J Wynia, yes I should have pointed out the free vs expensive side of the argument :)
Apols in advance if this is a really dumb question.
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?
Thanks.
Hi James,
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.
Post a Comment