I think perhaps one of the most important points that haven’t been made here in either you article or any of the comments is that any distributed SCM can act/behave/look-like a centralised SCM. Simply take one of the “distributed” repositories and canonicalise it as a “canonical” or central repository. This is not unlike how we operate in OpenSolaris where for the ON consolidation we have a canonical onnv-gate, which all ON putbacks go to.

http://blogs.sun.com/webmink/entry/a_niche_the_size_of

I was intrigued to read what Stephen O'Grady recently published about distributed source code management (DSCM) in one of his signature Q&As. He makes a number of interesting observations, but I was interested by the omission of a whole thread of analysis around the assertion Mark Shuttleworth makes that merging is the key to source code management...]

Conceptually how you work under a DVCS is different in a number of ways that will slow adoption.

- Tools. There’s no IDE support for things like hg or bzr and they don’t hook up yet with other infastructure (like bugtrackers) as easily as cvs/p4/svn do. Frankly, I’ve no time for the idea that IDE support is a criterion for choosing something as important as VCS - it’s like picking a car for its door handles - but plenty of people don’t agree. For example, I think you can correlate Subversion’s adoption with Eclipse and IDEA having decent support for it.

- Patches. Patches become the unit of work and of communication not “commits” or “modules” or “LOC”. People working in OSS will be familiar, but even then distributed tress. Until teams treat patch/merge as muscle memory DVCS it will feel wrong. Handling patches is a whole new skill to learn.

- Accountability. A DVCS imo shines a hard light on /practices/, especially on managing multiple versions of the same code base. I’m not talking about methodology or governance here, but what people do in the field to get software out the door. IOW, if you have broken practices that lean towards forking, cut and paste, not splitting configuration from code, and finagling things on production, a DVCS will make that evident real fast.

- Control. In the commercial space, I can see classically trained SCM and release managers being out of their comfort zone with a DVCS. Things will need to be done so they can “see” the “real” code and feel like they’re on top of things. Also anyone who grew with a locking VCS (this includes Perforce), code ownership and fear or branching, might find the idea of anyone being able to checkin anything and everyone having a tree unsettling and chaotic (the answer of course is to control which tree is deemed “gold”).

Tools and patches management are easily solved. Accountability and control are much more contentious.

I am surprised you missed MySQL in your list. We have been using a distributed source control system since 2000. Our development process, which allows us to span multiple countries since all developers work from home, wouldn’t work without it.

Cheers,
-Brian

It’s not that I think we absolutely need the extra features, but they don’t “cost” much, and they have potential.