ThoughtWorks’ Developers Favor Distributed Version Control Systems

Martin Fowler has conducted a survey on ThoughtWorks’ software development mailing list to determine how some of the version control systems (VCS) are perceived by developers. He also wrote a review of most prominent VCSes comparing centralized and distributed systems.

The results of the survey were:

The participants had the option to rate 9 VCS as Best, OK, Problematic, Dangerous or No Opinion, the last meaning they haven’t used the respective VCS. “Active Responses” is the total number of respondents excluding those with “No Opinion”, while “Approval %” is (Best + OK)/Active Responses.

While this is not a survey made on a large number of subjects, the results show a subjective perception within an organization, ThoughtWorks, and might be used as an indication of VCS’ perception in other organizations.

git and Mercurial, two open source distributed version control systems (DVCS), had the highest approval rates, over 95%. Subversion, an open source centralized VCS, also had a very good approval rate at 93%. The worst rated were commercial VCSes: IBM’s ClearCase, and Microsoft’s VSS and TFS.

All respondents have used Subversion, 85 git, 84 CVS, while Bazaar has been used by only 17 users out of 99. One conclusion is that VSS has been used by a fair number of respondents (77) but it managed to collect only 3% approval.

These results sustain Fowler’s initial remarks on version control systems. Based on discussions with other ThoughtWorks employees and collaborators, Fowler concluded that there are 3 VCSes which are generally accepted, and consequently are recommendable: Subversion, git and Mercurial. This means that one needs to choose between a centralized VCS and a distributed one. According to Fowler, a distributed VCS is better because it “opens up lots of flexibility in work-flow, but that flexibility can be dangerous if you don't have the maturity to use it well”. Subversion is good because it:

encourages a simple central repository model, discouraging large scale branching. In an environment that's using Continuous Integration, which is how most of my friends like to work, that model fits reasonably well. As a result Subversion is a good choice for most environments.

And although DVCSs give you lots of flexibility in how you arrange your work-flows, most people I know still base their work patterns on the notion of a shared mainline repository that's used with Continuous Integration. Although modern VCS have almost magic tools to merge different people's changes, these merges are still just merging text. Continuous Integration is still necessary to get semantic consistency. So as a result even a team using DVCS usually still has the notion of the central master repository.

Fowler’s review of VCS continues by remarking the strengths DVCS has against centralized VCS:

• Speed – not having a local copy of the repository, Subversion is slower especially when working with a server located on a different continent.
• Connection – DVCS can be used even when a network connection is missing.
• Branching – DVCS encourage branching:

DVCS encourages quick branching for experimentation. You can do branches in Subversion, but the fact that they are visible to all discourages people from opening up a branch for experimental work. Similarly a DVCS encourages check-pointing of work: committing incomplete changes, that may not even compile or pass tests, to your local repository. Again you could do this on a developer branch in Subversion, but the fact that such branches are in the shared space makes people less likely to do so.

Fowler noted that centralized systems are better at handling binary files:

There is one particular case where Subversion is the better choice even for a team that skilled at using a DVCS. This case is where the artifacts you're collaborating on are binary and cannot be merged by the VCS - for example Word documents or presentation decks. In this case you need to revert to pessimistic locking with single-writer checkouts - and that requires a centralized system.

Fowler expressed a low opinion on ClearCase and TFS:

Two in particular generate a lot of criticism: ClearCase (from IBM) and TFS (from Microsoft). One reason they get a lot of criticism is that they are very popular on client sites, often with company policies mandating their use (I'll describe a coping strategy for that at the end).

… developers I respect have worked extensively with, and do not recommend, these products.

VSS was considered the worst choice:

Before I finish with those behind the threshold, I just want to say a few things about a particularly awful tool: Visual Source Safe, or as I call it: Visual Source Shredder. We see this less often now, thank goodness, but if you are using it we'd strongly suggest you get off it. Now. Not just is it a pain to use, I've heard too many tales of repository corruption to trust it with anything more valuable than foo.txt.

This is a subjective opinion on VCS and does not compare actual capabilities these tools have. The Better SCM Initiative makes an in-depth comparison of 28 version control systems, but it does not rank them. It lets the user discover which is the best VCS based on some key features: Atomic Commits, Files and Directories Moves or Renames, Intelligent Merging after Moves or Renames, File and Directory Copies,  Ability to Work only on One Directory of the Repository, Tracking Uncommited Changes, Documentation, Ease of Deployment, and others.

Scott Chacon wrote a post defending git and explaining why he believes git is better than Mercurial, Bazaar, or SVN: cheap local branching, everything is local, git is fast, git works with any workflow, and a few other reasons.

Of course, every developer or team has its favorite CVS. What is yours? What are your great stories or horror stories to tell?