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).
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
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.