I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model
###DVCS The working model of DVCS is that you are doing isolated development. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.
###CVCS The working model of CVCS (in particular Subversion) is that you are doing collaborative development. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.
#Other differences#
Other differences between svn and git/hg, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).
I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.
Personally, I have no problems with working with a CVCS.
- I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
- When I experienced merge-hell, it was in situations where it would have occurred in both
svnandgit/hg. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.