First of all, use git for version control. It is modern, works great and the majority of developers are either comfortable in using it or want to start using it.
Its a pain in the arse to learn, overcomplicated for 90% of the cases it is used in. How many people actually need a distributed version control."
(I use Git. It is powerful and useful, but the justification for using it in the article isn't really great. No mention of Mercurial or other version control systems).
Also, many of Git's most powerful features have nothing to do with being distributed. Easy branching and merging, private versioning, bisect, rewritable changesets, stash, and the ability to cherry-pick individual changes within a file to commit, back out or stash could all theoretically be built into a centralised system.
Perhaps there is something to be said for Mercurial, but unless you were previously on Subversion it's certainly not that it's easy to learn.
But who cares, because Git or Mercurial can be used in a centralized manner if you want. But it doesn't have to be. That's why it's good.
- Central repositories handle me working on a plane. Same thing.
- Central repositories handle your Chinese subsidiary being constrained to a slow and spotty pipe (they actually exported our tree with git-svn and used git on their end--this was at a NASDAQ company, it's not like anyone was cheaping out, it was the best available).
That you are willing to work around the deficiencies of centralization does not mean they are not deficient. Don't be ridiculous.
They're not the 90% case, anyway, almost by definition. =)