Re: [Monotone-devel] "prune-branch" cert implementation issues.

[Nathaniel Smith]

On Sun, Jun 05, 2005 at 05:53:07PM -0400, Michael Stone wrote:
> I'm attempting to give people a clean way to mark a revision as
> "no-longer-a-head-for-branch-X".  There are two use cases for a feature
> like this one:
> 
> 1) To ignore old branches which have subsequently been merged into the
> mainline.
> 2) To mark revisions as unsuitable for merging.

(1) seems to be handled just as well by having a purely-advisory cert
that just says "hey, I think this branch is finished".  Various sorts
of history browsers could make good use of such a thing.  But if for
some reason I decide that I'd like to ignore that and revive the
branch (it happens), then it's actually convenient to be able to
update to the latest head, etc., and certainly killing off the head
does not actually help me in any way I can think of?  I don't see what
altering monotone's definition of "heads" buys us.

(2) is actually incorrect to handle this way.  The goal is not to
prevent people from merging some bad code into some good code; we
can't do that in a distributed system.  Maybe someone has already done
the bad merge, and you just don't know about it yet... there's no way
for you to tell, and there's no cert you could add that would be other
than ineffectual.  What _will_ work is something like "disapprove",
that commits the inverse change.  It basically inserts something into
the system that says "kill this code whereever you see it"; now it
doesn't matter if someone has already spread the bad code around,
because when they eventually merge in the disapprove node, the bad
code will get stripped out again.

The more compelling use case for this, I guess, is the "dead end
development" ones -- "I made some revisions, but, eh, I want to
abandon them".  I'm not sure about this case either -- generally the
way in monotone to say that one piece of code supercedes another is to
make the superceding code a descendent of the superceded code, so
there's some vocabulary for dealing with this case already.  But maybe
someone wants to argue this has some advantage...?

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen