With clones: article seems confused as to whether these are local clones or multiple remote repos[1]. If multiple remote repos: != branching, and horrendously wasteful. If local: almost exactly what I described, though they're making a repo for every existing branch; many other suggestions online suggest maintaining a "pristine", and it then becomes what I mentioned. And read the disadvantages section, it's pretty large. And this is one of the most-described means of branching; duplicating the repository because named branches are such a PITA.

Bookmarks: local only, no info ever reaches the server - ie, no label on a separate branch, it's just yet another anonymous branch.

Named branches: new head even when merged and closed, default push pushes all branches, so very difficult to use locally only if you have more than one remote branch (say, prod, qa, testing, dev. You now have to "hg push -b prod qa testing dev" just to prevent pushing your local branches. Or is it a separate push for each branch? I forget. And what if there were 20? 2000?). If you allow new remote heads, suddenly everyone will get tons of branches as you add more developers, name collisions / too many useful ones used up long ago (mybranch12a7c9?) - this is desirable how?

Anonymous: an artifact of any concurrent version control software, not a feature.

[1]: 2nd paragraph of: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

edit: summary: Git = friendly to multiple developers. Such as effectively every business environment. Mercurial = friendly to a single developer (in that case, yes, it's admittedly much easier), as long as you always push all branches.

Clones: I have seen a number of places talk about using separate repositories for branches in mercurial, but that's not how many people work these days. Just as with git, there are less efficient ways to do things.

In the article you linked to, the author is recommending against using separate cloned repositories, I agree with him.

Bookmarks: As of mercurial 1.6, bookmarks aren't local only and can be pushed.

Named branches: you don't have to push everything, just do

  hg push -r .

and it will only push the current revision, and any unpushed parent revisions. The linked article mentions this and talks about aliasing it to "hg nudge". If you do that, you have the same behavior as git.

I think git is a solid tool and that it can work well for many teams. I also know from personal experience at 3 different jobs that mercurial can work effectively for teams.

"hg push -r ." is new to me, though it makes some sense. How did you find that one out? "." is hardly a revision; it's a repository in every other command, from what I can remember (haven't used it since I initially learned mercurial).

And I'll have to see how well bookmarks function - not sure what my work repo runs.

"-r" is the revision flag for the revision to push out. "." is a shortcut that just means "the revision that the working directory is at" (same as hg identify would show).