Version Control: The Future is Adaptive

The Version Control space is undergoing a renaissance right now thanks to the increasing popularity of Distributed Version Control Systems (DVCS) such as Arch, Bazaar, DARCS, Git, Mercurial, Monotone and SVK. Many really smart people believe these systems have the potential to dramatically change how software is built and I agree with them! But which ones actually will and why? I think the answer to that lies in a closer examination of the criteria teams use to adopt collaboration tools.

Beyond market acceptance, there are 6 main criteria I consider when evaluating collaboration tools:

1. Reliability
2. Adaptability
3. Usability
4. Extensibility
5. Integration
6. Administration (including Total Cost of Ownership)

The order given above is the one I use for version control tools – different collaboration tool categories deserve different orders. Every team is different so the criteria they consider may not be identical, but the ones above are those I’d expect every team to include in their evaluations.

While few people would be surprised to see Reliability at the top, few systems do a really good job of delivering the features that implies, so I plan to return to Reliability in another post. Today though, I want to explain why I think Adaptability is #2, even if that makes me “dumb and stupid” in the eyes of one of my heroes. 😦

If you haven’t seen it already, I recommend watching the Google video of Linus Torvalds talk about Git. He makes a lot of excellent points about the advantages of Distributed VCS. Unfortunately in my mind, he also suggests that anyone using Central VCS tools, particularly CVS and Subversion, is dumb and stupid. I strongly disagree! The future of version control is neither Central nor Distributed – it’s Adaptive. It’s all comes down to the numbers …

I remember once being told that to a pure mathematician, there are only 3 interesting numbers: 0, 1 and infinity. Why? These numbers represent Nothing, Something and Everything.

Likewise, in the field of collaboration, I think there are 5 interesting numbers: 1, 2, 10, 100 and 1000. These numbers represent:

• an Individual
• a Partnership
• a Team
• a Company
• a Community

Once upon a time, Version Control tools only helped Teams and Companies work more efficiently. Today, Distributed Version Control helps across the whole collaboration spectrum – from Individuals to Communities. I’d like to stress that point again because I suspect many teams and companies are currently dismissing DVCS because of its reputation for solving Community needs. Yes, it does that very well, but the very best DCVS tools (including Bazaar and Hg) are also personal productivity tools, just as IDEs are. Not all DVCSs are equal for personal use though. Be sure to select one with very low administration overheads, e.g. tools that support creating version stores without requiring a database running.

So if Distributed VCS is so useful at both the low end and high end, why won’t it completely replace Central VCS? The answer to that is twofold. Firstly, Central VCS can and does actually work quite well right now for many teams and companies. It may never be as flexible as a more powerful approach, but there are processes (e.g. Continuous Integration) and tools (e.g. JetBrain’s TeamCity) that partially compensate for that. To be more blunt, many teams are probably only using 20% of the features in their Central VCS tool – just like every other bit of software installed on their computers.

Secondly, many companies like central systems and their current workflows. They want to add flexibility to how they work, not be lectured to about throwing out everything and using a different process. Given this, I think that some of the Distributed VCS tools are being overly elitist in telling users that “distributed in the only way”. A better way is to support how many teams work right now (with the same number of commands), while giving them smarter ways of forking and merging for larger bits of development. Having learnt from that journey, teams are then better placed to adopt more of a distributed process without the inherent risk of changing before they have that knowledge and experience.

Adaptability is the answer. From little things, big thing grow: using the same adaptable tool across that spectrum is what I want. In the middle of that spectrum, I want a tool that supports different workflows so that I’m not fighting it if and when my team decides to change how it does things. And I want a tool that runs well on all the major platforms, because my broader development team (including software engineers, technical writers, graphic artists and quality engineers) are most likely using a mix of Linux, Mac OS X and Windows.

In summary, I think the world needs tools that scale across the collaboration spectrum, from making one person more productive to making a community interact better. The only certainty in software development is change. Tools must be adaptable to different teams, different workflows and different platforms.

As a member of the Bazaar development team, I guess it’s pretty obvious as to which tool I think is best! See http://bazaar-vcs.org/Workflows for an overview of the numerous workflows Bazaar supports. For those most comfortable with the central approach, http://bazaar-vcs.org/Tutorials/CentralizedWorkflow shows how Bazaar can be used in a centralized way, using the same commands people expect: checkout, update and commit. Even if you only ever use Bazaar this way, it is still more powerful than Subversion and CVS thanks to features such as true rename tracking and intelligent merging.

Ultimately, Bazaar rocks because of 2 main reasons. Firstly, it has a very active community behind it lead by some very smart people. Secondly, it started with the goal of being a tool people will love to use, so user-centered design followed. Next week, I’ll be looking at usability more closely: It Takes a Community to Raise Great Software.