Ease of use is a fairly subjective thing, but I include this section here because I believe most people agree that a DVCS is somewhat more difficult to use and understand than a CVCS.
Returning once again to my multi-threaded programming comparison, this is not entirely unexpected. Concurrency is inherently more difficult. Multi-threaded programming is far more challenging than writing code for a single isolated thread.
I’ve watched many people climb the DVCS learning curve, and they all seem to stumble on the same obstacles.
How can our team work without a central server? (Answer: You don’t have to.)
With all these repository instances, how do I know which one has the official version of our code? (Answer: Whichever one you designate.)
How can it be okay to commit changes without merging them first? (Answer: The DVCS remembers the ancestry of your change and allows you to do the merge later.)
What happened to revision numbers? The version of my tree is e69de29bb2d1d6434b8b29ae775ad8c2e48c5391? What’s up with that? (Answer: The DVCS is using cryptographic hashes to store things by content.)
Most people who reach DVCS enlightenment will agree that it was worth the climb.
But it can still make sense for organizations to consider things like training costs as they evaluate a transition. I can’t express this any better than Greg Hudson did in his 2004 essay[21] “Undiagnosing Subversion”, so I’ll just quote him: “In many environments, a shallow learning curve is the most important feature of a version control system.”