Right now we use Subversion for all of our client projects. We are actually pretty sophisticated Subversion users. Our main workflow consists of:
Many would consider that Subversion is not up to this development strategy, but careful use of the tool means we have surprisingly few problems with this. The main weaknesses of Subversion are the one obvious one: no ability to work offline from the repository, and a second which is that Subversion tracks files and this causes headaches when we are refactoring the physical design of a project. In practice, anything but the very smallest physical design refactorings can't be done whilst there are live feature branches.
In practice we're not looking for a tool right now that we will switch to and throw away Subversion. We're going to need to build some experience in the use of a new tool, and this means we need interoperability between it and Subversion.
Both Mercurial and Git have tools for this. The problem with Mercurial's tools are that they don't work. Having tried several repositories, even the newest and cleanest ones wouldn't create a workable Mercurial repository. On the other hand, I've not seen a single repository that has caused Git problems.
Between Mercurial and Git things seem much better though. The hg-git extension allows for Mercurial to check out a Git repository and then Mercurial can be used for development and push changes back up to Git. This seems to imply that we should be using Git to bridge back into Subversion, but having Git repositories won't stop people from using Mercurial if they prefer that tool.
The interoperability between Git and Subversion seems to be good enough that for simpler projects we should be able to use either Subversion or Git as it suits individual developers. The problem on more complex projects is that there is no support for svn:externals (or anything quite like them) in Git. I suspect that the correct way to deal with this, especially in our Python projects, is to find ways to stop using externals through packaging a lot more of our library code into pip installable distributions.
My preference right now is to use Git rather than Mercurial. I think if you're using the tools from the command line there's little enough to choose between. Personally though I much prefer to have a graphical check in tool which at least allows me to properly review file diffs as I build a check in. Git Cola seems to fit this perfectly without being overly complex. The closest I've found for Mercurial is Meld which isn't anywhere near as usable (for Subversion I use kdesvn). The Git index works quite well here as i can break changes within a single file up into several commits with Cola which is really nice.
The other main tool that I like on Git is Git flow. Git flow implements our existing working practice on top of Git in such a way that the entire process is very simple to do. Much simpler than in Subversion even. Git flow even has decent bash completion.