Whether cloning is recommended way of branching in Mercurial or not?

Question

In this article author says:

I was naive enough to think that branches living in entirely different directories was a thing of the past. How SVN of them. I cannot imagine living my life making local clones to effectively deal with long running branches. The book literally says:

"In most instances, isolating branches in repositories is the right approach."

Um, no thank you. It turns out that the more I get into branching stuff, the more I understand why they advocate that you clone to branch. Everything is on one track - you can't commit something and then easily leave it there for work later and ignore it for the time being, which is what I use branches mainly for. It's like Mercurial is a one-track mixer...

and so on.

In other source, for which I cant find link now, I read, that Mercurial developers use cloning for branching.
It is strange for me that in Mercurial, where branching is 'first-class' concept - branches can be created just by commits from non-heading revisions - cloning linear repository is mainstream way of branching.
Is it true at all? Or probably it was true in the pas? What history this issue have?

ps
I remembered where I noticed words about that Hg devs use cloning - it is popular Steve Losh's article:

I personally don’t like this method and don’t use it. Others do though, so it’s good to understand it (Mercurial itself uses this model).

Answer 1

The article to which you link was written in 2008, that's 5 years ago, and it was inaccurate then. Steve's article to which you link:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

is much better, and while it was written in 2009 it's been routinely updated. It clearly shows that Mercurial can do git-style branches (it calls them "bookmarks"), or clones as branches, or named branches (which git lacks) or anonymous branches (which git lacks).

The Mercurial developers themselves use various types for various purposes as described here: https://www.mercurial-scm.org/wiki/StandardBranching

Which roughly boils down to:

• named branches for stable and release
• bookmark (git-style) branches for individual features
• clones for different access groups (crew vs. matt's repo)

Answer 2

Short answer: No.

Long answer: Cloning is convenient when you don't need branches at all. Like working on a fast patch, fixing few doc mistakes etc. Cloning is intuitive and fast to do, doesn't require you to read a book or keep in mind what branch are you working on. This approach frees one slot in your brain by recording branch name as your current working directory.

So, for simple cases you don't need branches (you will still produce anonymous branch in your clone that will have to be merged into main line sooner or later, but nobody cares).

Cloning is a good entrypoint, and soon you will be ready for advanced concepts. But from my experience with ~50 repositories on Bitbucket I can barely remember any with branches, even though everybody knows that branches are convenient for maintenance and bug fixing of time proven stable versions.

So you need to figure out yourself if you need advanced branching strategy for your project, and the sole recommendation I can provide is to read DVCS branching (with Mercurial) presentation by David Vega, which contains pictures worth of thousand words.

Answer 3

Im now reading Bryan O'Sullivan Mercurial-book which cited in this article on GitHub and came across this phrase:

In most instances, isolating branches in repositories is the right approach.

GitHub author is just cut it from context - in book it doesn't have meaning that "cloning is a mercurial-way for branching", Sullivan just says that:

Its simplicity makes it easy to understand; and so it's hard to make mistakes.

(for novices as I understood), and in next paragraph he begins to describe more advanced techniques of branching:

If you're more in the “power user” category (and your collaborators are too), there is an alternative way of handling branches that you can consider.

By the way chapter where this phrase occur named "Managing releases and branchy development".

So it is obvious that phrase in the Mercurial-book author does not meant anything from Chacon's interpretation in his article on GitHub. Chacon is simply incorrect.