In an earlier post, I discussed that you should decide and promote new ideas as either incremental changes, or disruptive new innovations. If you try to describe it the wrong way, you won’t get the adoption you want, and many of your users will be confused and annoyed by your new idea.
Distributed Version Control has walked into that problem.
I don’t think it was a conscious decision, nor am I blaming the DVCS community. However, the fact is that many people in the development community look at DVCS with more confusion and less acceptance than they should.
If you search for comparisons between a centralized VCS and DVCS, you’ll find one consistent answer: “DVCS doesn’t need a central server.” Unfortunately, that answer is correct, but unhelpful.
First of all, most successful uses of DVCS have a central server. If you’re going to ship code, you need to build it from some location. That’s probably a central VCS server. The claim that DVCS doesn’t need a central server makes users think it is really just an incremental change from other systems such as SVN.
That sets them up to fail when migrating from VCS to DVCS. In fact,Joel Spolsky has written a great article on “Subversion Re-Education” to address this problem. If you’re struggling with migrating from SVN to Hg, or your team is struggling, check out that article, and the entire tutorial.
To me, DVCS is a major disruptive change over traditional Centralized VCS system. Where traditional VCS systems manage changes to files, DVCS manages changes to entire repositories. When you commit changes to a traditional VCS server, you are committing the current version of each file into the central repository. When you push changes in DVCS, you are applying all the changesets in your local repository to a shared repository. When you issue an update command in a traditional VCS system, you are getting the current version of every file from the central repository. When you issue a pull request in a DVCS system, you are merging all changesets in a shared repository into your local repository.
The differences in the terms above may seem small, but they have a large impact on the mindset you should have regarding operations using DVCS. It’s a disruptive change: You have your own repository. Any sharing activity involves a merge operation between repositories.
This change helps you see why DVCS has so many proponents. It fits the way teams work now. You can make small changes, make small commits, and have many small incremental changes in your local repository. I do a commit after writing a test. I commit after making that test past. I commit again after any refactorings. Rinse, Repeat. I push (to share the code) after I finish a story card. Commit is at the granularity of a code change. Push is at the granularity of sharing with other team members. I can’t do that in a centralized VCS system. “commit” and “share” are the same thing. That change is disruptive; it’s not incremental.
By thinking about DVCS as operations between repositories, you likely won’t accidentally create multi-headed repositories or any of the other issues that sometimes plague DVCS systems. Once again, I won’t exhaustively list what can happen, but refer to Joel’s hgInit tutorial. If you are interested in migrating to DVCS, read that tutorial. It’s a great explanation of DVCS systems. If you’ve got experience in traditional VCS systems, remember this:
DVCS systems give each user their own repository. Sharing code with teammates means sharing repositories and history between repositories.
The Mercurial (or git) documentation is quite good, and will explain its commands in these terms. It will be clear when you work through docs or examples whether a command works with your local repo, or between repositories.
I’ve written before that I do like DVCS, and I think it is a big improvement over traditional centralized VCS systems. Anytime I’ve had trouble getting someone to appreciate DVCS, they’ve been viewing a DVCS system as an incremental improvement over traditional VCS systems. That mental model made them under-appreciate the advances DVCS offered. It also led them to use a traditional workflow that played to DVCS’s weaknesses rather than its strengths.
DVCS may not be right for every organization, or every team. But, viewing it as a traditional VCS without a central server will not lead to a successful adoption. Viewing it as a disruptive change that fits better with today’s team-oriented development processes will put you on a better path to success.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.