[Monotone-devel] Killing heads, again

[Bruce Stephens]

Suppose someone (with suitable access) decided to start rearranging
monotone.texi, and committed a revision on n.v.m that removed
monotone.texi (the idea being that Makefile would create it from
smaller files, I guess).  

Anyway, it's resolved that that's not a good idea, so how do you
recover?  

I guess you could merge, but edit out the changes from this fork, but
that's annoying and (if I understand the lifetime issues correctly)
can't remove the deletion of monotone.texi as one would hope (once a
file is dead in any line, it stays dead).

You could just ignore that fork, but that would make it impossible to
use propagate and things, and generally be annoying.

You could try and get everyone to do "db kill_rev_locally" on all the
relevant revisions, but that seems a bit crude, and not always
appropriate.  I guess this could probably be helped using "db
set_epoch", so you could make sure the dead revisions don't reappear
accidentally?

You could do it by distrusting that user's key, I guess, or by writing
suitably convoluted get_revision_cert_trust hooks, and persuading
everyone else to use them.  But those don't seem attractive.

The model I'm imagining is a group of developers who generally trust
branch certs signed by two keys, and who commit revisions and review
revisions in the obvious way, and revisions that get signed by two
people get generally accepted.  

But sometimes you'll inevitably get a fork where the best thing is
just to start again, and I'm not sure how that could be done in
monotone.

One idea would be always to use a new branch.  But then it would
probably be convenient for smallish changes to reuse the same branch
over and over again.  But that would cause the same problem, I think:
you'd end up with these "small changes" branches having multiple heads
(because in some cases you wouldn't want to propagate the change back
to the main branch).

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 am I missing?  This seems like a common use case: you do some
work (committing at the end of the day or something), but after a
couple of days you decide that's not the best way to do it after all,
and you want to discard the work (or at least mark it so it doesn't
get in the way).