RFC: dealing with dead, anonymous feature branches

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Fri, 2010-05-07 at 19:37 +0200, Dirkjan Ochtman wrote:
>> On Fri, May 7, 2010 at 19:34, Martin Geisler <mg at aragost.com> wrote:
>> > I discussed this idea with Jan Sørensen from aragost and I had at
>> > some point mentioned that we're "afraid" of many heads because the
>> > number of heads is a term in the running time of some of our
>> > protocols. He suggested that one could make a "canonical dead
>> > head", that is, merge all dead heads until there is only a single
>> > dead head in the graph.
>> 
>> I think this is the important bit, it potentially alleviates a bunch
>> of perf issues. We should get this before we argue about the other
>> things.
>
> So what happens when someone resurrects a dead head by committing to it?
> Answer: merge is confused.

I don't think there should be any problem if someone resurrects the dead
Y head I had in my examples.

If you're thinking of the synthetic merges mentioned above, then they
should be hidden so that nobody can resurrect them. You would only be
resurrect the heads that belong to the visible graph. Something like
this:


  [A] --- [B]
     \
      [X] --- <Y>
         \
          [Z]


If Z is closed ("killed"?) by W, then W and Y are merged by a hidden
dead merge changeset H:

  [A] --- [B]
     \
      [X] --- <Y> ---- <H>
         \            /
          [Z] --- <W>

The user can not see H, so he can only resurrect Y or W (by making a
child of Y or W). We will never merge H or other hidden changeset into
the visible graph, so I hope that means that the fake merge happening in
H wont affect the merges made with real, visible changesets.

> There are three categories of algorithm that are affected by heads:
>
> index-only: in memory, not a performance issue
> index-and-data (eg tags): mostly solved already by the tag cache[1]
> over-the-wire: probably addressable in the discovery protocol
>
> [1] It might be worth dropping dead heads from tag calculation

Yeah, good point.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/