I think what you're missing is DVCS is a subset of "version control". A large percent of developers have moved from CVS to SVN and for the past few years are he

I think what you're missing is DVCS is a subset of "version control". A large percent of developers have moved from CVS to SVN and for the past few years are hearing Git is the successor to SVN. So they are comparing the new hot version control Git to their previous SVN. A lot of these people don't care about the distributed aspect, just whether git is better than svn for their version controlling needs. I think the thing that generated much of the initial git confusion for svn users was a lot of the git documentation at the time were devoted to using git in a very distributed, very branching, type of of manner, which while it's awesome that it's possible, is needless complexity for many dev teams. Particularly this post was passed around as the gold standard: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ . A lot of svn devs were used to a pretty simple work flow. Checkout the current branch in dev, make some edits, commit/push. Rinse, repeat. On many teams no one other than the lead dev/release master would ever need to even do a merge. Now show this team the above git branching model, which suggest Bob can pull a feature branch over from Alice, make some commits and push back, but wait Sam has also needed to pull Alice's to make some commits, and merges in her latest changes from Develop which conflict with both Bob and Alices current. Now you have the lead dev or release manager wasting hours trying to figure out this merge mess with 3 broken repos and the PM demanding Sam's changes in develop are needed for a hotfix by Pat yesterday. I hope you can see the massive complexity increase in the way a lot of teams were initially told to use Git. Once people figured out everyone could pull and push from a centralized repo (Github heavily helped this) and that branches should (for a certain type of dev team) always be pushed/pulled from the central repo instead of shared peer to peer, the workflow was much simplified. Git with a central repo is more than likely better than using svn for many teams. The easy branching and offline commits are benefits whether a team needs the "distributed" aspect or not. It's apparent that you really understand and use a DCVS, many people do not. It's important to realize on many projects devs don't want or need to become experts on DCVS, but could still benefit from using Git over svn. For a lot of open source projects, merging and reviewing patches is a big part of the project as that's how new code gets in. For a startup team, any time spent on dealing with a VCS system is time not spent developing the product.