The D in DVCS

Just a reminder that the D in DVCS stands for “Distributed”, not “Disconnected” or “Decentralized”. This is a centralized model (from

And this is Distributed:

Note that in the first picture, you’re reliant and dependent on the server for a lot of operations. Note that in the second picture, the only distinguishing feature of the Server is its label. It’s really just an agreement or convention on what the “central” server is. But we can draw all sorts of more interesting pictures, like:

Which is not hard to do at all with Git. The nice thing about the distributed model is that it opens doors to ways of working that simply aren’t possible or feasible with centralized VCS. You can try and work around it, but ultimately the centralized model of VCS is inferior.

It’s not just the “I can work on an airplane” factor (which is nice) or “I can branch and merge like it’s going out of style” effect (which is nice), but the architecture of a distributed model enables patterns and styles of work that can provide a real, measurable impact to a team’s productivity.

DVCS is not the opposite of CVCS, nor is it its complement. It is the next evolutionary step forward, one that no team I’ve encountered has ever chosen to go back on.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in git. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #959()

  • Sadly I’ve seen more than a couple teams that tried going DVCS only to go back to CVCS.  For many developers, I think the comfort of Subversion+TortoiseSVN is hard to leave behind.  I’ve worked with some teams that I would actually discourage from going to a DVCS.  While I love git, some developers just aren’t ready for it… 

    • I think you have to be comfortable with the cmd line to move to git and most ppl are not.

    • In many ways Mercurial+TortoiseHG provides a much easier transition from SVN+TortoiseSVN.

  • That does not look like a happy integration manager.

  • Anonymous

    Jimmy, nice post!
    Pretty much in agreement with you.
    In reply to Matt and Joey: If coming from svn, Mercurial might be simpler. And the tools are better on windows (ie VisualHg for VS integration and TortoiseHg  )