Mercurial Workflow: Feature seperation via named branches

Martin Geisler mg at aragost.com
Wed Jun 15 10:26:59 CDT 2011


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.

> 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.

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

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.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial mailing list