[PATCH] add support for marking changesets as dead

Martin Geisler mg at aragost.com
Thu Feb 3 05:01:47 CST 2011


Matt Mackall <mpm at selenic.com> writes:

> Ideally, if we're using both concepts together, people will only ever
> regularly abandon changesets that are still in the liquid state. In
> other words 'freezing' should be interpreted as a promise not to later
> 'abandon' a changeset.
>
> A picture might be helpful here:
>
>         |          |
> frozen  1  liquid  2  abandoned
>         |          |
>
> (Ancestors are on the left, descendants are on the right)

I talked briefly with marmoute on IRC about how the boundaries move and
we are both confused.

If we assume that Alice and Bob both have the same changesets, but
boundary 2 differs in their two repositories. How do they know who is
right?

If Alice moved the boundary to the left in order to abandon some
changesets and the does a 'hg push' to Bob, then how do we know that
Bob's changesets should be abandoned too?

The problem is that it could just as well have been Bob that had moved
the boundary to the right.

Alice:

       |               |
  [A] -1- [B] --- [C] -2- [D]
       |               |

Bob:

       |       |
  [A] -1- [B] -|- [C] --- [D]
       |       |

what to do?


This issue does not come up when one adds extra changesets to the
history since there is a clear distinction between the two cases.

Speaking of extra changesets and the direction of the kill... what about
adding the kill marker as a child of the changeset it kills:


  [A] --- [B] --- [C]
             \
              [*]

Here * kills off B and C.

If you change your mind, then you could cancel * with another changeset:

  [A] --- [B] --- [C]
             \
              [*] --- [+]

here I imagine + has some meta data that says that it cancels * and so B
and C are live again. I also thinks this becomes kind of magic too fast,
but it's a way to encode the intent into the graph. We'll need a similar
mechanism with the pushkey markers.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/


More information about the Mercurial-devel mailing list