[PATCH] add support for marking changesets as dead

[Wagner Bruna]

On 02/01/2011 06:15 PM, Matt Mackall wrote:
> On Tue, 2011-02-01 at 11:21 +0100, Martin Geisler wrote:
>>> And that, I think, is conceptually broken. I can know that I want "1
>>> and descendants" dead long before I know what I want to replace it
>>> with. Having to commit an extra dummy cset (note that we actively
>>> reject empty csets!) to have a living head at this point "sucks" from
>>> a user POV.
>>
>> Sort of -- see it this way: the dead changesets are no good if you want
>> to back up a linear track of development. They are good if you have
>> different (concurrent!) lines of development and you want to kill one of
>> them, in which case you already have a branch point in the past.
> 
> I want to focus on just one issue for a bit: your choice of direction.
> Your proposal is about "the set of heads x and all its _ancestors_ that
> are not ancestors of heads not in x". That's not exactly a simple rule.
> In revset notation, it'd be something like '::dead() and not ::(heads()
> and not dead())'. And if I want to prune back to something that's not a
> branch point, I'm forced to introduce dummy changesets. 
> 
> My proposed approach is "the set of changesets x and all their
> _descendants_" with no additional caveats ('dead()::' in revset-speak). 
> Not only is this conceptually simpler, it allows you to precisely prune
> a line of development at any point without adding additional changesets.
> 
> So, is this pruning to non-branch-points a real issue? My contention is
> yes. First, 'branch points' are not an easily identified thing in
> Mercurial, short of poking around at graph views. We don't have a simple
> way of asking 'what is the first ancestor of x that's only ancestral to
> x' without doing something like the big revset expression above. 
> 
> Second, it's going to be common for people to want to back out only a
> portion of changesets after a branchpoint: "my first 5 changesets were
> fine, but the last 5 I pushed were broken".
> 
> Third, people are also going to want to mark things discarded well
> before they're ready to commit anything new: "I need to throw out the
> junk that moron Bob committed on the stable branch today but I'm not
> planning to commit anything else there until an actual fix for stable
> shows up".
> 
> As far as I can see, you've latched onto the ancestors direction because
> it's the obvious way to do thing when you've chosen to store the pruning
> markers as new commits, but aside from that, it's not a good choice.
> Given the constraint that everything is communicated in history, it
> might be the right answer, but that constraint doesn't apply. There's no
> good reasons for DAG pruning instruction to live in the DAG when we have
> another channel available.

IMHO it'd be far less confusing for new users if changeset metadata were also
used for "abandoning" topological heads, since it is very similar in concept
(and possibly implementation) to closing named branches (to some extent,
closing a named branch and reopening it at another point can be used right now
for "abandoned" topological lines).

Perhaps the non-branch-point issue could be solved with additional metadata on
the revision that closes a head/branch: it could simply point to its first
"abandoned" ancestor - or better yet, a set of ancestors. So everything
between those ancestors and the closing revision would be considered as
"abandoned".

In Matt's example,

0-1-2-3-6
   \   /
    4-5

to mark 1 and all descendants as abandoned, we'd put a mark from 6:

0-1-2-3-6-7(pointing to 1)
   \   /
    4-5

so only 0 would be "non-abandoned". To mark everything as abandoned, 7 would
point to 0.

For... "un-abandoning" an abandoned head, IMHO an empty changeset would be
fine; I don't see it as a "dummy" revision because it carries important
information: all the metadata explaining why the abandoned line was
"un-abandoned".

Alternatively, we could simply restrict this metadata to topological heads, so
any commit over the closing revision would effectively cancel it; then, after

0-1-2-3-6-7(pointing to 1)-8(pointing to 3)
   \   /
    4-5

only 3::8 would be abandoned.

Regards,
Wagner