Skip to main content

Distributed SCM: You Don't Get It Until You Got It

Posted by tball on September 12, 2008 at 10:49 PM PDT

Chris Adamson recently blogged, "what are the advantages of distributed SCM, beyond the globe-spanning mega-projects?" I've been hearing that question for a long time; it started whenever a new engineer joined a Sun project and had trouble getting their head around TeamWare. But it's hard to answer that question except with, "try it for a while and you'll see."

The reason that's a hard question to answer is because a distributed SCM creeps up on you and changes the way you work, in a subtle way you don't notice until you have to work on a single-repository SCM again. The reason is that branching is very easy on a distributed SCM and so you use it all the time; it's so easy that you rarely notice you are branching. Anytime engineers want to work on something independently, whether it be in different cities across the globe, between co-workers, or just by themselves working on two projects at once, all you do is clone the repository you want to work with from some other copy, which becomes the parent of your new copy. Make any changes you like in this copy, then commit them when you like them as usual. Just like any other SCM, right? Wrong, as the commit only happens in your copy; you need to merge your copy with its parent to share it with the parent's other child repositories.

It sounds like more work, but it's the opposite because it fits better with how most software engineers go about their jobs. Child repositories can work as safety nets, so you can try wild experiments and if they don't work, just delete their repositories (and no need to broadcast your failures with the world like with a branch in a single-repository SCM). Independent bug fixes need parallel code reviews? Just keep them in separate repositories and there won't be any risk of accidentally changing them before they are merged. A couple of team members are working on a side-project? Just copy a repository to hold your shared work, then copy individual ones so you don't step on each other. As time goes on you'll find you are cloning copies all over the place, and your productivity improves since your SCM system supports how you juggle your responsibilities.

Most source control management systems support branches, but the big difference with a distributed SCM system is that branches don't have to be explicitly created since you are always working on one or more branches. Branches with single-repository systems can be a headache many team avoid whenever possible; SCM advocates may claim otherwise, but that's been my experience working with CVS, Subversion, and Perforce. Developers are conceptually branching and merging as they write software all the time, whether it be in big teams or as individuals, so their version control system should make branching and weaving as easy as possible. It's counterproductive for a tool to fight the natural way most of us work.

It reminds me of when I got my first pair of noise-canceling earphones. I put them on, didn't hear anything different, and thought they were useless; but after wearing them for awhile, I took them off and was shocked at how loud my "quiet" room really was. I couldn't hear the normal noise until I grew accustomed to quiet.

It's that "fighting the flow" issue which makes it so hard to make the case for distributed SCM systems. When you start using a distributed SCM, it may seem to be the same experience as a single-repository SCM, and so what's the big deal? The "it's a big deal" moment happens when you switch back to a team using a single-repository, and then you find that not being able to easily branch and merge is a constant irritant and productivity drain.

Oh, and I forgot a reason why even Chris might make the switch: distributed SCM systems work fine off the grid, such as on airplanes. Try doing that with your CVS or Subversion-based project!

Related Topics >>



When someone with your experience answers something with ", "try it for a while and you'll see.", I tend to believe it.

But I'm still not convinced by your arguments; expect by the fact that the local repositories can provide faster access, all the branching/merging stuff you mentioned could be handled by a single-repository SCM. At least by a good one, like Subversion, where the cost of branching is O(1), and merging is simple (at least in my opinion).

-- Felipe

PS: didn't know you worked for Google now...

Yeah, Google uses Perforce and it's been a hard transition for me because of how obvious the benefits a DSCM would offer to an engineering team this size. One problem we have is that we must be 24/7 with reliability that has lots of trailing nines, which makes major engineering process changes very difficult.

Nice article :-)

I used CVS and Subversion for many years, and we still use Subversion at the office. But I've recently switched my home repositories to git, and I'm finding many advantages. I outlined one of them in my blog. See and

But Google uses perforce, don't they? Is it hard to give up your DSCM?