Mercurial Workflow: Feature seperation via named branches
mercurial.peter at bourgon.org
Tue Jun 14 12:11:42 CDT 2011
Related question: if your repo does get in a state where it has too
many named branches, is there some process by which you can
"anonymize" a set of them? If not properly supported, maybe some
hackery with the convert extension?
On Tue, Jun 14, 2011 at 6:30 PM, Matt Mackall <mpm at selenic.com> wrote:
> 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
> 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.
> Mercurial mailing list
> Mercurial at selenic.com
More information about the Mercurial