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

Then that child is a head.  

I'm not trying to prevent committing children of these revisions, I'm
just trying to have a way of marking them so they stay out of the way
of default "update", "merge", "propagate" type operations.

So I'm imagining a group of developers working on the same branch, and
one goes off intending to develop something over two or three
revisions (so not really enough for a new branch), and then decides
it's not a good approach after all.  So that developer marks it as not
a head, and then nobody needs to do anything with it.  However, if
someone wants to, then they can easily revive it by committing a child
as you suggest, or (depending on the implementation, I guess)
approving it on to another branch, or doing an explicit_merge.


Does that make sense, or does it seem to you like a particularly weird
way to develop?

It's kind of how we do things at work: we use a CVS repository
together with scripts which commit multiple files more or less at
once, but before committing, we send out proposed changes to one or
two people for review.  

And now and again, we decide not to commit a change at all, or not to
commit it now (because it'll interfere with some imminent release or
something).  This doesn't happen all that often, but we certainly do
abandon changes now and again.

So I'm imagining how we might work using some other system.  Our way
of working tends to involve using CVS working copies as distributed
branches, and we email patches for review as, well, patches.  And I'm
not convinced that reviewing works that effectively---I suspect it
would be better to commit first and review afterwards, where it's easy
to see things in context, and convenient to make minor changes.  

And I think monotone might make all that work, and allow us to keep
reasonably stable branches (we could all use a get_revision_cert_trust
which requires two keys for the branch or something, so we'd only see
a revision after review).  I think that would all work,
anyway. (Except for a convenient way to abandon a proposed change.)