Mercurial Workflow: Feature seperation via named branches

[Matt Mackall]

On Wed, 2011-06-15 at 17:26 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > 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.
> 
> I read this sentence several times, thinking you talked about the
> *performance* of named branches -- it was only after Henrik pointed it
> out to me on IRC that I discovered that you talk about how named
> branches are permanent.
> 
> My point above was an answer to Mads' comment about scalability of named
> branches, i.e., their performance. You know that I'm aware that named
> branches are permanent.
> 
> I agree with you that people may not want permanent branch names in the
> history, though I fail to see why -- Subversion has permanent branch
> names and I have not heard people complain about that.

I'll tell you why: people generally don't go to Subversion from Git,
where they learned that branches were lightweight in the first place and
thus zero thought needed to be given to naming.

We get people asking this question at least daily on IRC.

> > 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.
> 
> I know that things can fall apart when they are not designed to handle
> the load. I just don't consider it a pathological idea to solve every
> issue on its own named branch.

Great, you can try to redesign the code so that it scales to 50k
branches while maintaining backward compatibility. I don't think it's
possible.

Until that's shown to be feasible, branch-per-bugfix is something we
should discourage.

> But let me start by adding a note to 'hg help branch' that point to the
> bookmark command.

Sure.

> By the way, maybe we should begin using some bookmarks in Mercurial
> itself: Henrik and I could push the patches for abandoned changesets as
> a branch with a bookmark and you and others could give much better and
> faster feedback in the form of commits instead of just chatting here.

Hmmm, that'll change everyone's workflow against crew. I'd rather do
this experiment in another repo.

-- 
Mathematics is the supreme nostalgia of our time.