Mercurial Workflow: Feature seperation via named branches

[Matt Mackall]

On Tue, 2011-06-14 at 14:02 +0200, Martin Geisler wrote:
> Mads Kiilerich <mads at kiilerich.com> writes:
> 
> > On 05/10/2011 06:15 PM, Arne Babenhauserheide wrote:
> >> I just added a new workflow to the wikipage and to my own site. I hope it’s
> >> interesting to you! I wrote the original guide for PyHurd.
> >>
> >> → http://draketo.de/light/english/mercurial/feature-seperation-via-named-
> >> branches
> >> → → short: http://draketo.de/node/446
> >>
> >> →
> >> http://mercurial.selenic.com/wiki/Workflows#Feature_seperation_through_named_branches
> > ...
> >> #### 1. New feature
> >>
> >> first start a new branch with the name of the feature starting from default.
> >>
> >> <pre>hg branch feature-x
> >> \# do some changes
> >> hg commit -m "Started implemented feature-x"
> >> </pre>
> > ...
> >> #### 5. Close the branch when it’s done
> >
> > Note that
> > http://mercurial.selenic.com/wiki/StandardBranching#What_not_to_do
> > mentions a common mistake: using long-lived branch names for
> > short-lived feature branches. One reason for that is that Mercurial in
> > algorithms, APIs and UI haven't been designed to scale in number of
> > branches like it scales in number of changesets.
> 
> It sounds like you are letting the internal implementation dictate how
> people should organize their workflows. I think it is a shame if we have
> to to that.

The reason that note is there is that the #1 question we get about named
branches by a wide margin is:

"I made a temporary branch, how do I get rid of it?" 

The permanence of named branches is NOT an implementation detail, it's
bedrock design. Thus, telling people not to create them willy-nilly is
solid advice.

(Those questions predominantly come from people who've been exposed to
git, which is rather unique in that branch names are completely
ephemeral.)


Also, I think you underestimate how badly things can go algorithmically
for people who are not aware that particular things aren't designed to
scale. For instance, we've had people who've tagged essentially every
commit in a 100k cset repo. That's simply not going to work well and
we're not going to be able to tweak things so it does. 

Similarly, if people adopt a model where they do every bug fix on a
named branch on a large project, they're probably going to suffer when
they've got 50000 branches no matter what we do. The design simply won't
support it (never mind that we don't have the resources to re-engineer
things for a single user with a pathological use case). And they won't
start to feel the suffering until they're quite a ways down that road.

-- 
Mathematics is the supreme nostalgia of our time.