jump to navigation

Version Control: The Future is Adaptive June 21, 2007

Posted by Ian Clatworthy in Bazaar, Collaboration, Open Source.
trackback

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.

About these ads

Comments»

1. teki321 - June 23, 2007

I prefer mercurial:
http://www.selenic.com/mercurial/wiki/
– really good documentation
– friendly community
– fast

2. João Marcus - June 25, 2007

Bazaar rocked for me for a while, but it sucked a lot for *one* bug that rendered Bazaar useless for my major projects: it doesn’t handle filenames with non-ascii characters (bzr add * spits a unicodedecodeerror). It’s a known and very nasty bug, as it blocks me from using Bazaar. It’s easy to fix, but the fact that I ran into such a bug made me wonder if Bazaar doesn’t suffer from a sucky encoding handling.

3. Horst Gutmann - June 28, 2007

Great article :) Since I discovered DVCS for me, I put nearly everything under version control, no matter if it’s a LaTeX document or a coding project.

But as I guess quite a few people out there I’m currently jumping from DVCS to DVCS since every single one of them has tons of advantages and disadvantages. I guess the whole development will really become interesting when one or the other might become popular at the scale of svn right now in the OSS world.

4. It Takes a Community to Raise Great Software « Agile Teams, Open Software, Passionate Users - July 3, 2007

[...] software built faster, give DVCS a go. You’ll never go back to CVS or Subversion again and, with an adaptive approach, you’ll never need to [...]

5. Martin - July 3, 2007

João, you are probably seeing a unicode error on bzr add if you have filenames that are incorrect for your current encoding – for example if you have utf-8 filenames and are in the C locale, or iso-8859-1 filenames in a utf-8 locale.

The main difference is that Bazaar is trying to read the filenames as unicode, whereas most other systems just read them as byte strings. So Bazaar has trouble in this kind of case. We may switch to not trying to interpret them.

6. João Marcus - July 4, 2007

Martin, IMO the best way to deal with such problems is to do exactly what you just mentioned: never try to interpret file names. Not being able to add a file because of encoding inconsistencies is a serious issue for us, poor souls that can’t rename the files.

7. Martin - July 4, 2007

João, if we just treat them as byte strings it will appear to work, but there may be other problems: you may not be able to check out or use the files on other platforms, particularly Mac or Windows where the filesystem really knows about Unicode, and we may have trouble displaying them. But we are looking at changing this.

8. Wanted: Rock Solid Version Control « Agile Teams, Open Software, Passionate Users - July 11, 2007

[...] many central VCS users by assuming that what’s best for him must be best for everyone else – a point I’ve addressed elsewhere, I fear a really important point of his has got lost in the follow-up [...]

9. Joseph Wakeling - July 12, 2007

I think you may have misinterpreted some of Linus’ message, so perhaps you are not dumb and stupid after all … ;)

Although obviously he doesn’t favour a centralised workflow it seemed to me that what he was attacking was not centralisation per se but software that forces this choice upon you. DRCS can be used in a “centralised” fashion if desired and (as he notes) in some cases actually allows for running a [i]better[/i] centralised system.

It seems to me that “Adaptive” is not a matter of whether the system can be used in different workflow environments—DRCS allows for all the possibilities—but how user-friendly it is across the spectrum.

10. Version Control: Plug-ins vs Toolkits « Agile Teams, Open Software, Passionate Users - July 18, 2007

[...] perfect version control tool and there never will be. That’s why extensibility is #4 on my list of evaluation criteria for VCS tools. There will always be pressure on these tools to enable new ways of working, provide [...]

11. Version Control: Design for Integration « Agile Teams, Open Software, Passionate Users - July 30, 2007

[...] on my list of criteria for evaluating version control tools is Integration. Software exists to get things done and it [...]

12. beza1e1 - August 14, 2007

I made a similar list for my study thesis. Maybe you’d like to comment on that?

http://computerroriginaliascience.blogspot.com/2007/08/how-to-evaluate-dvcs.html

13. Ian Clatworthy: “The Future Is Adaptive” — Version Control Blog — Interoperability, Ideas, Bazaar/bzr, - October 7, 2007

[...] “Version Control: The Future is Adaptive; [...]

14. There are only three interesting numbers « Audible Smirk - April 24, 2008

[...] pulled this together from two sources . Can’t find who the original attribution should be credited to [...]

15. rajkaran - June 13, 2009

hi this is rajkaran …..
cld anyone help me………
please send me mailing lists of persons who are working with version control system

as am doing thesis on “Significance of Version Control System: Software Development Process ”

i would be very thankful for your help guys………..

16. rajkaran - June 13, 2009

my e-mail id is rajkaransingh@ymail.com

17. Wade - December 19, 2011

The only problem with SCM’s adapting to what companies do is that companies often do things for bad, historical reasons. If an SCM allows them to work in a bad way, they’ll continue to do so. Sometimes to effect a paradigm shift, companies have to be forced to change their ways.

I think this is Linus’ main message: the paradigm has changed, and if you’re smart you’ll pay attention and start adapting how you work to fit the new model. He just uses shocking statements to make you pay attention.

That’s not to say that git is the end-all-be-all. However, most of the objections corporations have about git, bzr, or Mercurial are ridiculous straw men, put forth simply because they don’t want to face the prospect of changing. It’s much simpler to throw out some BS about SOX compliance and keep doing things the same old way than it is to figure out how to improve the company.

18. how to use size genetics - December 14, 2012

I absolutely love your blog and find many of your post’s to be just what I’m looking for.

Does one offer guest writers to write content for you?
I wouldn’t mind creating a post or elaborating on a few of the subjects you write related to here. Again, awesome site!

19. http://tinyurl.com/cmpgprice01671 - February 5, 2013

I personally had to show this particular posting, “Version Control:
The Future is Adaptive Agile Teams, Open Software, Passionate Users” together with my friends on facebook.
Isimply just needed to disperse your terrific writing! With thanks, Maude

20. twitter hack - April 24, 2013

We are a group of volunteers and starting a new scheme in our community.
Your web site provided us with valuable info to
work on. You have done an impressive job and our entire community will be grateful to you.

21. meet people - April 25, 2013

Fantastic site. Lots of useful information here. I’m sending it to several friends ans also sharing in delicious.
And of course, thanks for your sweat!

22. minecraft beta - May 5, 2013

I have read a few good stuff here. Certainly worth bookmarking for
revisiting. I wonder how much effort you place to create
this kind of wonderful informative web site.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: