Speaking of the examples in this article:
hg update -c
In the case of merge output, when you've fixed a file, you simply run
hg resolve filename
hg resolve --list
No it's not. Speaking from experience here.
Edit: Okay, here's some real data:
It shows that git wins by most metrics, with a few exceptions. Mercurial's push/pull format is particularly good.
Edit in response to above edit: those stats are for Mercurial 0.4 through 0.9.5. The current version is Mercurial 1.3.1. Seeing as there have been piles of speedups, including several that fell out from Python modules getting rewritten in C, I find that page highly dubious.
Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fast enough that it doesn't matter'
Classic hg branching came into different forms: 1) a tree clone and 2) the hg "branch" commands.
1 can be very slow on a large tree and can often require you reconfigure your tools to go look in a new place.
2 is permanent. Your code now forever references the name of a branch so you have to stop and think about whether it's really the right thing to do.
In either case, anything that requires me to stop and consider the cost of an operation makes the operation less valuable. Where that cost kicks in varies for people. Is it minutes? Seconds?
As a former perforce user, there were definitely plenty of things I wouldn't do there because they weren't instant. In git, I tend to make decisions based solely on my desired outcome.
For example, running status to see the state of the working directory. With svn it takes a couple of seconds on small repositories, and it can easily climb above ten seconds on larger repos. With git it very rarely rises above a second, even with a cold disk cache. The difference in speed is large enough that I find myself running "git status" far, far more often than I ever ran "svn status".
A more dramatic example is 'git bisect' which, when given a command, it will do a binary search on the repository to find the commit which caused that command to begin to fail (return an exit code of something other than 0).
Speed is a feature.
Yes, darcs used to have (and probably still has, though to a lesser level) an issue with merge times blowing up exponentially. Anyway stevejohnson took issue with the statement that Mercurial performed roughly on part with Git, you might want to take the issue up to him not davidw.