Re: [Monotone-devel] Killing heads, again

[Nathaniel Smith]

On Thu, Jan 12, 2006 at 01:58:16PM +0000, Bruce Stephens wrote:
> 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).

Correct -- file (and directory) lifetimes currently use what we call
"die-die-die merge":
   http://revctrl.org/DieDieDieMerge

Fortunately, the situation you describe is uncommon, and not a
showstopper even if it happens (you _can_ just create a new file named
monotone.texi, and it's a bit of a pain for history browsing and
merging, but you'll probably survive).

But, this sucks, so I would consider this a serious flaw with the
current history model.  It's not unsupported because we don't want to,
it's unsupported partly because we can only do so much at a time, and
partly because there are some unresolved questions about how exactly
to make it work technically.  These are somewhat described at:
  http://venge.net/monotone/wiki/HistoryBlueSky

It seems like the real solution to this problem is to support revival,
though.  What really happened was that one thing was done on mainline,
and then people changed their mind, and they undid it again.  The
Right Thing is just to record that sequence, no?  If we had proper
revival, it would be straightforward to express this.

There are also some technical advantages to doing it that way.  You
always have to assume that once a revision is public, someone may have
based work off of it... possibly work on an entirely unrelated part of
the project, they just picked the latest head and started hacking.
This is sort of a subtle point... the sneaky trick behind disapprove
is that it handles this case; once you inject an anti-patch into the
system, then the normal merge/propagate/etc. workflow will make sure
that that anti-patch automatically seeks out and destroys the bad
changes in exactly and only the places where it should.

This, of course, requires that you actually _have_ real anti-patches,
which in the case of deletes we don't!  (Sutures may cause similar
problems if we ever add them; merges are also complicated to unwind
from... in fact, it suddenly occurs to me that one of the standard
unsolved problems in merge tech, known as "rollback"[1], is exactly
the merge unwind problem!  Oh, that's interesting.)

[1] http://revctrl.org/Rollback

I don't know when we would be likely to get support for revival,
though :-/.  There are a lot of interesting questions in this area...
people _do_ seem to want to be able to reach back in time and
rearrange history in various ways, and it's actually quite
straightforward to support even fancy stuff like quilt-style systems
with commit reordering and suchlike; git and mercurial both have
systems to do this built in.  None of these systems address the
problem of how you manage the distinction between immutable and
mutable revisions, though, or distribute your patches-in-progress and
share the workload, etc... so I think things like this are definitely
worth thinking about!

> 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?

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."