Source Control Comparison: Subversion vs TFS vs Mercurial vs Git

Discuss “the best” Source Control and you will get differing opinions and a good punch-up lively debate. 

Considering the value of the source code to an organisation, it is something that should be taken seriously and the rather consultese answer regarding “the best” is “it depends”… anybody who has lost sleep over Visual SourceSafe corruption or ended up running nasty Analyze & Repair commands will tell you that VSS is BAD NEWS!!!

The following subjective comparison may help if you are evaluating Source Control options and have similar needs to our small 10-man dev team; we are a Microsoft Gold Partner and the team consists of predominantly Microsoft developers (Visual Studio, ASP.NET, SharePoint, MS-SQL etc.). 

In our evaluation, the key requirements were:

  1. Good branching
  2. Good merging
  3. Good Windows integration
  4. Ability to work disconnected/remotely
  5. Good Visual Studio integration [actually this isn’t a big factor, more a nice-to-have]
  6. Easy to backup/restore
  7. Setup [easier wins, all other things being equal]
  8. Cost [although happy to shell out for licenses if there is value to be gained]

The options under consideration were:

  1. Subversion
  2. Team Foundation Server 2010
  3. Mercurial
  4. Git

The options we ruled out were:

  • Visual SourceSafe [unstable & dangerous, branching support iffy]
  • TFS2008 [would have incurred licensing $ cost; debating the value proposition is beyond the scope of this post]

Note that all the options were free for us in terms of licensing (as a Gold Partner we have licenses for TFS2010) however variable cost in terms of setup and on-going maintenance.

1. Subversion


  • Familiar to most of the team
  • Low resource requirements
  • Good tools & shell integration


  • Not distributed

2. TFS 2010


  • Full integration with VS2010
  • Integration with work items & projects
  • Flexibility


  • Flexibility [I know.. but in order to configure it “just right” it can be time-consuming!]
  • Heavyweight back-end requirements [Two server setup recommended, backup/restore more costly & time-consuming]

3. Mercurial


  • Acceptable Visual Studio integration
  • Good shell integration
  • Good merging algorithms
  • Good branching
  • Distributed (fast as it is local!)


  • Learning curve [not too steep, but a change nonetheless]

4. Git


  • Distributed (fast as it is local!)
  • Good branching
  • Good merging algorithms


  • Visual Studio & Windows integration 
  • Learning curve [steeper than Mercurial due to less advanced tools/integration]

The clear winner on paper and in practice was Mercurial for us… it’s really fast, distributed across all developer workstations & laptops, with a central repository, allows quick and easy merging of branches and has good enough integration with Visual Studio and Windows. We also managed to preserve history migrating older projects from Visual SourceSafe, and developers working on laptops are able to disconnect anytime without thinking much about it. 

I’m going to post more in-depth about Mercurial shortly, it really is “the best” for us. 

Sadly Tumblr a bit lacking with regards to creating pretty images or even HTML tables to show green/red for each product vs requirement. That’s what you get for being lazy… technical debt! 

Edit: I stand corrected on the integration of Git, thanks @andybritcliffe – Git extensions to the rescue:

I still prefer Python to Cygwin mainly because I had it installed already.. a tenuous subjective argument for which is “better”, but all other things being equal…

10 thoughts on “Source Control Comparison: Subversion vs TFS vs Mercurial vs Git

  1. How about adding this to the factors: the ability to handler non-merge-able items (word docs/image/drawing, …)? For SVN, at least you can lock. With the Distributed options, you seem to have to put those files in another system.

    1. Not really true. I routinely have image files in my Git repository along with source code. I’m not sure why you’d think that they need their own repo; merge conflicts are handled for each file independently.

    1. Although with TFS 2010 we can claim enough licenses for our dev team through Gold Partner status (not true with previous versions; I think 5 licenses were included..) the resource requirements especially in terms of backup & restore are far greater with TFS.

      If we hadn’t gone with a distributed system we would have had even greater problems in the recent bad weather where several team members were snowed in or stranded.

      I think TFS 2010 would be worth a look if we had a bigger dev team but as we are around 10 it’s manageable and the benefits of the additional functionality TFS offers would probably only be realised by a bigger team.

  2. Do any of these support Microsoft Word, Excel, and PowerPoint files ?
    What limitations on supporting those kinds
    e.g. only if they have been converted to .pdf
    does not merge these kinds of files
    only 1 checkout per file allowed at a time

    1. I don’t know about TFS, but Subversion, Git, and Mercurial will store any file reliably. They don’t generally handle *conflicts* in binary files with any sophistication, usually asking you to simply choose one version or the other, but there’s no problem with having the files in the repository.

  3. I think he mentioned above that he had Sharepoint.. That what sharepoint is for.. documents and office files. For source … SCM is what its used.

Leave a Reply

Your email address will not be published. Required fields are marked *