[PATCH] add support for marking changesets as dead

[Augie Fackler]

On Feb 1, 2011, at 3:24 AM, Martin Geisler wrote:

> Augie Fackler <durin42 at gmail.com> writes:
> 
>> On Mon, Jan 31, 2011 at 4:10 AM, Martin Geisler <mg at aragost.com> wrote:
>>> # HG changeset patch
>>> # User Henrik Stuart <hg at hstuart.dk>
>>> # Date 1295774638 -3600
>>> # Node ID 7bd977fdbca15da3c69ea7ef01df987b95475b11
>>> # Parent  0d1dca7d2a041cb1cb6c6bd90608aa87068bde02
>>> add support for marking changesets as dead
>>> 
>>> Marking a changeset as dead is, if it is a head, a way to delete a
>>> branch of development in a safe, append-only manner. A dead changeset
>>> "kills" all its ancestors that are not reachable from a non-dead head
>>> and make them subject to revised propagation rules that are outlined
>>> below:
>>> 
>> 
>> We had discussed (at one point) doing this with pushkey to communicate
>> deadness rather than another marker in a changeset's extra field. Why
>> not that approach?
>> 
>> Not necessarily critical (yet), curious about the motivations of this
>> approach rather than pushkey. In particular, with this scheme you
>> can't ever delete dead node data, whereas with pushkey you could
>> delete dead nodes without risking re-exposing them later.
> 
> If you change your mind about a dead head, then you just commit to the
> ancestor of the dead head. So if you have
> 
>  [A] --- [B] --- [C] --- [D*]
> 
> where D is dead, then you can resurrect C by
> 
>  hg update C
>  # make your changes
>  hg commit
> 
> and end up with
> 
>  [A] --- [B] --- [C] --- [D*]
>                     \
>                      ----------- [E]
> 
> The D changeset will then no longer be pushed or pulled anywhere and
> wont play any role any more.
> 
> You are right that there is no way to resurrect C without making a
> change. If you want to resurrect C, then it's presumably because you
> want to base work on it, and so this may not be such a bit problem in
> practice.

Having to add a changeset is not strictly my objection. More of it is that if we use pushkey for death markers, we can propagate deadness without having to actually retain the (potentially sizable) changeset and file node data. That property would be very nice for large installations of Mercurial.

Also, why not start the implementation and exploration of dead heads as an extension? If you do it as an out-of-tree extension for a little while, people can try it and offer feedback before you lock in the behavior and then can't make backwards incompatible changes.

I'm also more of the feeling (which I think is Matt's feeling as well, but not sure) that the notion of "liquidhg" is intimately tied to death markers. In particular, the liquid/solid boundary can be thought of as an "always-live" marker:

[A] -- [B] -- [C] -- [D]
        ^             ^
        |              \-------- This revision is marked dead
        |
This revision
is marked as
the solid line

Otherwise you have no way of marking D as dead and B as live without clumsy dummy changesets parented off of B. That seems like a *major* disadvantage of not using pushkey.

> 
> -- 
> Martin Geisler
> 
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/en/services/mercurial/blog/