I will spare you the detail of what a dvcs is and just use my blog to opine, letting you read around the subject yourself, so I'll dive straight into comparing the main two contenders, Mercurial and Git.
I'm going to briefly cover a few of the advantages of Mercurial. I will update this comparison as I discover the inevitable complaints - if you're reading the comments please be aware that they might be responding to my errors and omissions so please do not engage in a flamewar here.
The Battle So Far
There is a commonly referenced list of reasons to use git and I'll begin by countering its author's perception that Mercurial doesn't score as well as git.
Mercurial Matches Up
According to that list mercurial matches up on some items:
- Everything is Local
- Any Workflow
- Easy to Learn
- Small (git's windows build is huge)
- Easy to Learn (git is vastly more complex to comprehend and the consequences of some features and actions are very non-obvious)
- Cheap Local Branching
Mercurial Doesn't Focus on Pointless Things
There is a criterion in the list on which mercurial may well fall behind Git, "GitHub," but I argue that GitHub is mostly pointless, people don't socially network much based on which tool they're using to work, they network based on what they are creating and mercurial has mailing-lists a wiki and a freenode channel. These are great tools for networking around mercurial.
Mercurial Has Commit Support Tools
The list says Mercurial doesn't match up on "The Staging Area" but Git's Staging Area is complex to understand and Mercurial has the attic extension which is much simpler to understand and very flexible. The high flexibility combined with ease of understanding of Mercurial makes Git lose this round too.
Mercurial Has Excellent Trustiness
Much like Git, Mercurial has tools for creating alternative, more descriptive deconstruction of the changes resulting from a line of history and saving that as a second line of history branching from an earlier point where the two lines diverge, but the first line must remain. While it is often desirable to remove the old line of history, mercurial makes you take an extra step to ring home the gravity of the action and the effect it will have on collaborators.
Mercurial makes it clear to the user that this action actually constructs a /different/ repository to the one that collaborators have been working against. It does this by the straightforward and intuitive means of requiring the user to create a new repository from the line of history they want to keep, then requiring them to actually replace the old repository with the new one. Easy, takes a few seconds longer, but clear, effective and safe. The user also gets a chance to review the effect of their actions before committing to what they have done by giving the user two wholly separate, comparable repositories.