Mercurial Workflow: Feature seperation via named branches

Martin Geisler mg at aragost.com
Tue Jun 14 07:02:43 CDT 2011


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.

> This "new" workflow can be used in a way that makes that mistake. That
> might be intentional and ok and work for you and many others, but I
> think the descriptions should contain a clear warning about that.

Instead of trying to impose an unwanted "standard" way of doing things,
we should instead fix whatever needs to be fixed. I know that Sune and
Henrik has several hundred branches in their repositories and my clients
also use named branches in large numbers.

-- 
Martin Geisler

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


More information about the Mercurial mailing list