[Monotone-devel] Re: Killing heads, again

[Bruce Stephens]

Nathaniel Smith <address@hidden> writes:

> On Thu, Jan 12, 2006 at 01:58:16PM +0000, Bruce Stephens wrote:

[...]

>> So how about a variant of get_revision_cert_trust which is only called
>> on things which are heads and which gives a final determination, given
>> all the certs attached to a revision?  Then "heads", "propagate",
>> "update" and things could call that when appropriate, and, if we want
>> to kill a fork, we just mark the head of that with some suitable cert.
>> Would that make things too expensive---should there be a standard
>> "this is not a head" cert hardcoded (but subject to the usual
>> get_revision_cert_trust) to make things saner?
>
> What do you do if someone has already committed a new child?

As I said, the new child would be a head, and I regard that as a
feature: some of the time, we decice that a proposed change is good,
but not now.  In that case, I'm imagining we could mark the head with
one of these certs, and also tag it so we could easily find it in the
future, and then do an explicit_merge.  Or (depending on
implementation), just add a branch cert to make it a head of a new
branch.  

That also strikes me as generally useful: you fork a branch, but after
a couple of revisions decide that work would be better in its own
branch.  This might allow you to do that (presuming everyone
cooperates, or (I guess more likely) this all happens before you
sync).

I can understand why someone might not see the need.  If you're coming
from CVS or subversion or something similar, then you'd be used to
just committing things and fixing them in place.  

However, reviewing before integration isn't that unusual.  Aegis is an
obvious example, but GNU Arch people seem to work similarly: someone
develops in their archive, and when they've got something they think
is worth merging they say so, and the central coordinator merges the
patches (presumably after looking at them).

I guess what I'm suggesting is not unlike accept_testresult_change,
although I read that as only applying to update (whereas I'd want it
to apply to merge and propagate, too).

[...]