Does anyone use named branches?

[Peter Arrenbrecht]

On Thu, Oct 15, 2009 at 1:18 AM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> I keep wanting to like named branches, but I get consistently pushed away
> from them.
> In a world without branch naming, anonymous branches are implicitly named
> "default".
> Approximately 100% of the time, except during occasional brief merges, I
> want to have just one named branch active in any given repository. So if I
> check out my "1.2" branch, I want it to contain the named branch "1.2", and
> I'd really like Mercurial to update to the tip of that branch when I clone
> it. But instead, it updates to the tip of the "default" branch, and I then
> have to manually update to the tip of "1.2" by hand afterwards.
> I find that this behaviour makes named branches sufficiently unappealing and
> surprising that I never use them and always advocate against their use, even
> though they're notionally extremely useful in a medium-to-large team.
> Basically, the "clone, then remember to update by hand" requirement screams
> to me "and here's where you'll make lots of mistakes because you'll forget
> to take this step 40% of the time".
> Am I alone? Does anyone actually like the current behaviour?

I use them a lot, both with pbranch, and to track separate upstream
branches (see my series about improving transplant, where I give an
elaborate example). Sometimes the update to default after clone trips
me up, too. This especially with pbranch, where I have a single dummy
octopus-merge patch branch to pull together all the various
independent patches. I think that if a repo has a single head, clone
should update to it, whatever its branch name. For example, here's the
pgraph on top of Hg for my local deployment:

o    rel
|\
| \
| |\
| | \
| | |\
o | | |  bashcomp-meld
| | | |
| o | |  hgrc-defaults-in-parentdirs
|/ / /
| o /  graphlog-collapse-runs
|/ /
| @  transplant-merge-all
| |
| o  transplant-unless
| |
| o  transplant-merges
| |
| o  transplant-nochange
|/
o  default

-parren