[PATCH] add support for marking changesets as dead

Augie Fackler durin42 at gmail.com
Tue Feb 1 09:11:53 CST 2011


On Feb 1, 2011, at 4:21 AM, Martin Geisler wrote:

> Matt Mackall <mpm at selenic.com> writes:
> 
>> On Mon, 2011-01-31 at 22:41 +0100, Henrik Stuart wrote:
>>> On 2011-01-31 22:15, Matt Mackall wrote:
>>>> On Mon, 2011-01-31 at 11:10 +0100, Martin Geisler 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
>>>> 
>>>> I like this core concept. I think we need a scheme for marking
>>>> branches with something like 'do not display or propagate'.
>>>> 
>>>> However, as discussed at the 1.7 sprint, I still think we should use
>>>> pushkey[1] to implement this. For starters, it meshes well
>>>> conceptually with the liquid concept that's also going to be
>>>> communicated via pushkey.
>>> 
>>> I think that making it a core concept rather than pushkey-based
>> 
>> Uh, what? Pushkey is a core concept. It's how we distribute data
>> that's not an immutable part of history. Since your data is all about
>> changing history, it should use pushkey.
> 
> Well, "changing" is a bit of a misnormer here, it is more about
> appending more history, which will in turn hide some old part of the
> history.
> 
>>> Liquid and dead are, in my opinion, completely orthogonal and solve
>>> two different problems: tracking what's safe to modify, and telling
>>> everyone else that something's gone amiss.
>> 
>> I'm afraid this can only mean you haven't fully understood what
>> 'liquid' is about. The primary distinction liquid makes is 'these are
>> things that will never disappear' and 'these are things that might
>> disappear'. Whereas dead heads is distinguishing between 'these are
>> things we're keeping' and 'these are things you should drop'. To say
>> these are unrelated is.. puzzling. My mental models of how to
>> implement these two concepts are nearly identical.
> 
> I sort of see what you mean here... however, it was my impression that
> 
>>> (I told Martin to insist that pushkey wasn't the best choice at the
>>> sprint, but he must've forgotten). :o)
>> 
>> Nah, what he forgot was to tell you I thought you were crazy.
> 
> Ahem... :)
> 
>>>> Also, I think there are some problems with a cset-base
>>>> implementation that are unaddressed here. Fundamentally, lines of
>>>> development are not the thing we actually care about, not heads.
>>>> Consider:
>>>> 
>>>> 0-1-2-3-6
>>>>   \   /
>>>>    4-5
>>>> 
>>>> If I want to mark 1 and all descendants dead, it does not appear to
>>>> be enough to put a mark at 1:
>>>> 
>>>>    M
>>>>   /
>>>> 0-1-2-3-6
>>>>   \   /
>>>>    4-5
>>>> 
>>>> Looking at that last graph, it's not clear whether M was added
>>>> before or after 2. Thus it's not clear whether M kills 2 (case A) or
>>>> 2 invalidates M (case B).
>>> 
>>> The concept is invalidating ancestors, so you would commit a --kill
>>> changeset on top of 6 and a new child from 0 to make 0 alive. If you
>>> wanted M killed you would also have to commit a --kill on top of
>>> that, otherwise M keeps 1 alive.
>> 
>> 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.
> 
>> Again, dead "heads" are a boring special case of dead "anonymous
>> branches". If you're not talking about killing -whole lines of
>> development- after the fact, it's a non-starter. And killing branches
>> is logicially going to be about 'invalidating descendants' and not
>> 'invalidating ancestors'.
> 
> That is because you want to kill the branch before you've started a new
> branch. I imagined the dead heads to be used in cases where you do
> 
>  hg merge X
>  hg commit
>  hg push
> 
> Ups, bad merge!
> 
>  hg update revA
>  hg merge X
>  hg commit
>  hg strip --kill old-merge-head
>  hg push
> 
> or in situations where you pull in changes, rebase and let the old
> changesets stay behind as a dead branch.
> 
>>>> So the pushkey version is effectively an extension of history where
>>>> each cset has a deadness bit that's read/write.
>>>> 
>>>> [1] "Pushkey implementation" here means "something that's stored
>>>> with a mechanism outside of history and thus needs to be transmitted
>>>> via pushkey", eg like bookmarks. Pushkey itself doesn't implement
>>>> any sort of storage.
>>> 
>>> We'll then need to extend pushkey with enough knowledge about whether
>>> it kills heads here or there (push or pull) and compute much of what
>>> is already computed in discovery.
>> 
>> Extend pushkey? That's pretty much redundant. Pushkey is very
>> abstract, everything that uses pushkey defines its own add/remove and
>> list methods. I strongly suggest you actually look at how pushing
>> bookmarks work.
> 
> Henrik knows how pushkey works. What he is saying is that you would need
> to redo the computations done in the discovery protocol to figure out
> which (live) changesets that need to be propagated and which should not
> be sent anywhere.

We'd need to make sure there were appropriate hooks in the discovery module for the deadheads extension. That would be useful for other extensions anyway (I think hgsubversion might be able to use it in some kind of clever way.)

> Also, with pushkey, how will we solve the problem of cancelleing the
> kill orders? If I pull from A and get meta data that says "kill X", and
> if this is cancelled at A, then how do I know if I should push the kill
> order back to A or if I should delete my own?

You'd use pushkey to resurrect the head by deleting the dead marker via pushkey.

> That has always confused me about the out of history meta data, and the
> changeset based meta data avoids that.
> 
> -- 
> Martin Geisler
> 
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/en/services/mercurial/blog/
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list