Using named branches (`hg branch`) for feature branches isn't recommended.

[Ben Fritz]

On Jul 6, 7:02 am, Martin Geisler <m... at aragost.com> wrote:
> Peter Bourgon <mercurial.pe... at bourgon.org> writes:
> > Named branches give me exactly the behavior I want, seem to work
> > great, and are easy to understand by everyone on my team. But I hear
> > people saying things like in the Subject: often enough that it vexes
> > me a bit.
>
> One issue with using a new named branch for every issue is that most if
> not all user interfaces expect the number of them to be "small". As an
> example, there is no way to filter the output of 'hg branches', except
> by closing branches. There is also no way to limit the number of
> branches shown in places like Bitbucket and TortoiseHg.
>
> But I know that there are companies where they have several hundred
> named branches in their repositories -- Henrik's and Sune's company is
> the main example and they are both Mercurial developers.
>
> See also this recent thread for some advice from Matt:
>
>  http://mercurial.markmail.org/message/bclialai2wddj2le
>
> and try making a clone of this repository with ~60.000 changesets and
> 10.000 named branches:
>
>  https://bitbucket.org/mg/10k/
>
> Running 'hg branches' takes 3.6 sec in that repository on my machine.
>

I'd like to point out even with a test case deliberately designed to
illustrate "bad" performance with too many named branches, the time
taken for a "hg branches" command is barely worth mentioning. I work
with version control at work which takes MINUTES to do some
operations. Not to mention, other applications which take 10-20
minutes just to load.

If the only performance hit I will potentially suffer from branching
on a feature-by-feature basis is on the order of a few seconds, I'm
not going to think twice.

I think the stronger argument against using named branches is your
first one, that most user interfaces expect the number of them to be
"small". However, you note that closing branches is sometimes a way
around this limitation. I think it would be fairly common practice to
close a feature branch after merging it to the default branch, so even
this seems to be a very minor issue.

Personally, and based on my current understanding of how all this
works, were my company ever to adopt Mercurial (they probably won't,
at least not anytime in the near future), I'd probably want to use a
combination of named feature branches and feature clones. Which to use
would depend on how long I expect to keep working on the changes out
of the default branch in the "official" repository, and whether I need
to collaborate with others on the feature. I'd be much more likely to
use a clone for changes which are very small or easy, which I expect
to complete by myself in a few days at most and push back to the
"official" repository. For changes which I expect to take a few weeks,
and which I expect to need assistance from other team members, I would
probably choose a named branch so that it is easier to share the
changes without causing problems for anyone.

That said, I have only briefly glanced at the documentation for
bookmarks, so perhaps I have not considered all options fully.

As it stands now, I primarily use Mercurial for my own config files
and scripts, which I always just commit to default; and for Vim
development, where Bram currently accepts and applies all changes in
the form of a patch imported to a single changeset rather than
incorporating the changeset history of whomever developed it. So, I
currently have very little need for separating features at all.