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

[Matt Mackall]

On Wed, 2011-07-06 at 10:20 +0200, Peter Bourgon wrote:
> > Each commit has a field for what branch it's part of, just like a date
> > or username. And just like date and username, these fields are
> > immutable. Thus, a named branch is simply the collection of all commits
> > that have the same branch field.
> 
> This is useful information that I was not previously aware of. Thanks.
> 
> > If you want anonymous branches, you don't need to actually _do_
> > anything, it's a natural part how Mercurial works. Let's say we start
> > with:
> >  . . .
> > At this point Alice can be said to have "two anonymous branches", with
> > heads at "g" and "i". But when were these "branches" created? Any time
> > you create a new commit, you are potentially creating a new "branch"
> > relative to some other user. This is a fundamental part of how a
> > distributed SCM works.
> 
> Yes, I understand this perfectly. But this "split" in history required
> specific, simultaneous action from multiple actors on the same
> repository. And, it produces a undesirable (from a user-perspective)
> side-effect: when Charles runs "hg pull ; hg update default", his
> working directory represents whichever of Alice or Bob's lineage
> happened to have the most recent update.
> 
> The behavior I want is perhaps not well described as an anonymous
> branch. Maybe the better term is "secondary branch" or "hidden
> branch." If the default branch has an existing history
> 
>   a-b-c-d-e
> 
> in a central repo, Alice would run some operation that causes her next
> commits to be part of a new "hidden branch"
> 
>   a-b-c-d-e
>                `-f-g-h
> 
> The only difference between this "hidden branch" I'm imagining and the
> current behavior is that when Alice pushes, and Bob pulls and updates,
> Bob's working directory is still at changeset e. He must manually
> specify f, g or h to get to Alice's changes; at no point would "hg
> update default" ever switch to that lineage.
> 
> (I understand that I can simulate this behavior with bookmarks. But
> it's at the cost of violating #2, and introducing a new moving part in
> our SCM that needs to be managed, and that developers need to be aware
> of.)
> 
> 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.

This is probably too strongly stated.

The issue here is that unlike a Certain Weird But Popular SCM which
advocates using feature branches, named branches in Mercurial are
permanent, not throwaway. Thus, you shouldn't dive into using them
without some thought to managing their namespace.

I've updated the advice here:

http://mercurial.selenic.com/wiki/StandardBranching#What_not_to_do

-- 
Mathematics is the supreme nostalgia of our time.