Distributed VCS vs centralized VCS

I've been using GiT, a distributed VCS, for more than a year now. I don't find it cumbersome or hard to use at all. It just need a little shift in paradigm of how a VCS works. First things first, we just need to understand its concept of local and remote repository.

When you install DVCS and initialized a repository, this is your local repo. It resides on your local machine. When you do a commit, you are actually committing locally. This has several advantages.

You dont have to be online to commit your code. What does this gives you? The ability to track your changes. But one may argue that you can compare with Local History in your IDE. Question: Can you track the whole project changes with that? I believe that you only can track only a single file at a time. :) So, DVCS allows you to track your whole changes and 'save' it as a set. You might write a prototype program and it works fine. But let say you need to refactor it and something goes wrong somewhere and you lost track of what was changed that made it broke, can you track them back using the local history? Unless you are a masochist then I believe the answer is no.

You are free to develop and implement that experimental feature without the pain of doing merging that most popular centralized VCS gives you. Not just that, you are now able to do that OFFLINE and without the pain of creating a separate workspace/project.

You totally don't need a centralized repo to sync your codes with your buddies anymore. If you and your team work locally, you can just pull from each other and review each other's codes just by sharing a folder on the network, or create a 'bundle' and email it. Or appoint someone as the build manager and let him do the usual merging and build. You can have a 'Blessed' or 'Golden' or whatever name you want to give it to a main repo and work in a 'centralized' way if that is what you want.

Minimize broken builds. Now in my past experience, this thing is undeniably the most common showstopper for developers. Countless times I've been in this situation where somebody from a different timezone 'accidentally' committed half of what they supposed to and what happened was, the whole local team unable to do anything productive for the day. Worse if the team in the other timezone is celebrating holiday the next day. Or maybe somebody refactored a piece of code that another developer did a design mistake to tightly couple his code to it.

I'm not saying the CVCS is all that bad. It is simplistic but it relies too much on the network and developers to commit their code correctly.  Right now, if I am given the choice, I rather go with the DVCS instead of CVCS and I really recommend that you do too. Other than the shift in paradigm, another issue that most DVCS haters are having are just because they did not configure their client properly - this could be for so many reasons but I would say being lazy and impatient is the main issue as I never really have trouble using it. Take time to understand and I'm sure you'll like it as I do.