Re: [Monotone-devel] RFC: 'suspend' certs

[William Uther]

On 07/07/2007, at 7:08 PM, Daniel Carosone wrote:

> >  Anyway, I have another proposed solution.  It is a 'suspend' cert.
> >  It looks the same as a 'branch' cert in that it contains the name
> >  of a branch.  The effect of a 'suspend' cert is to remove that
> >  revision from any list of heads for that branch.  If all the heads
> >  of a branch are suspended, then the branch no longer appears in
> >  "mtn ls branches".
>
> I like the idea, but it seems specific to a particular usage - that's
> not necessarily a bad thing, but I'd like to consider the generalised
> problem for a moment, because there's a mechanism here that may be
> useful elsewhere too (without trying to reinvent policy branches).
> Just a little thought excursion/exploration, nothing concrete in terms
> of real requirements..

Okie.  BTW - I just pushed the suspend cert code in the  
net.venge.monotone.suspend-cert branch.  So you can play with my  
version if you like.

> For starters, it might be nice to generalise the cert form to
> something like a "branch-status:suspended branch.name" cert, leaving
> room for other statuses too (needs-testing, ready-for-integration,
> finished, merged, abandoned, and a list of other possible bikeshed
> colours).

Hrm.  I agree the idea can be generalised.  I'm not sure I'd bother to
put them all in one cert though.  Why not add a "needs-testing" cert or
a "ready for integreation" cert?

So, yes :) and when people want to do that the current design supports
the extension.

> This interpretation may include combined statuses (does foo trump bar,
> are they independent, etc).  Perhaps this interpretation also includes
> looking at some of the other status values that were on some (but not
> all) of the heads (a subsidiary descriptor for partial statuses). This
> seems like something to leave entirely up to user hooks, if at all,
> other than providing the raw descriptors.

Okie, so you could implement user hooks to make it all work.  Anything
in CS can be solved with another layer of indirection. :)

I think that is starting to get complex though.  I think I prefer the
simple solution.  Not least of the reasons for that is that I already
have it implemented.

> This reminds me of an earlier discussion about branch statuses. I
> think at that time we posited that the status value would be inherited
> down the ancestry tree until overridden by another cert on a
> descendant, leading to a kind of graph-colouring status. That got very
> quickly into looking like merging behaviour (though with the
> difference of being able to add certs to existing revs), and from
> there into certifying across to policy branches where merging is well
> defined.
>
> The "all heads" rule seems simple enough not to step into that
> territory and be useful in the meantime.

yup.

> >  Notes:
> >      - A suspend cert does not stop anyone from making descendants  
> > of the
> >  revision, and they'll appear on lists of heads just as normal.
>
> This seems fine, perhaps add some UI as a variant:
>
>  - if all heads of a branch are suspended, we could discourage (but
>    not forbid) the creation of new branch certs on that branch, eg via
>    commit, propagate, approve.  This means you need to do something
>    explicit to create the descendants (to prevent accidents), but you
>    can fork off a new branch name from here as normal.

I'd wait to see if that is needed first.  I expect branches to be  
suspended once they're
no longer in use.  Once they're suspended I can't see that committing  
to those branches
is any more likely that committing to a random (typo) branch is now.

> There c/should be a switch (--no-ignore-suspended, or something like
> --no-status more suitable to the generalised status form above?) that
> makes the status behaviour ineffective (so you can see the branch
> again in ls, so you can commit descendants, etc.)

There is an option (admittedly not wonderfully named), -- 
ignore_suspend_certs, that
causes the suspend certs to be ignored.

> >      - A suspend cert does stop merge from trying to merge the  
> > revision by
> >  default.  (I'm looking at putting the filter in
> >  project_t::get_branch_list(), project_t::get_branch_heads() and
> >  pick_update_candidates())
> >      - A suspend cert and update interact in a somewhat complex  
> > manner.  If
> >  all update candidates are suspended then they're all considered.   
> > If some
> >  update candidates are not suspended, then all the suspended  
> > candidates are
> >  removed.
>
> I'm less sure about these; they seem to cross from "don't worry about
> this branch" to "don't use this revision" which you rightly stated was
> better done with testresult or other certs.  I think the right
> behaviour falls out naturally from the 'all heads or nothing' rule,
> which applies to the use of the branch as a whole, not individual
> revs.

The reason for the merge rule was that I expect branch names to be re- 
used.  I didn't want a suspended revision from a previous use of a  
branch to cause a problem for the next user of a branch name.   
Ignoring suspended revisions in the list of heads achieves this nicely.

The update rule is a bit more tricky.  If the final rev in a branch  
is suspended, you should still be able to update to it easily.  But  
if if there is an un-suspended rev, then you should ignore the  
suspended one.

> For merge, perhaps don't try and merge a branch where all heads are
> suspended (unless the same --no-whatever switch is given). Maybe it's
> known they can't easily be merged, and that's why the branch was
> abandoned.  Or perhaps don't try and merge pairs of heads where both
> are suspended - but if there's a non-suspended (maybe new) head, that
> could merge with a suspended head, as would the also not suspended
> descendant be with the next suspended head. But really, I'm not sure
> any special behaviour is needed here.

Hrm.  I can see where you're coming from.  If I was going to go that  
route I'd just make merge ignore the suspend certs entirely.  If  
someone is working on a suspended branch then they'll know what  
they're doing.  I'm still worried about what happens when someone  
tries to re-use a branch name (for somewhat unrelated code) though.

> For update, the only special behaviour might be a "this branch is
> suspended" warning. If there's a single head, we should just update to
> it. If there are multiple heads (all suspended), the "pick one or
> please try a merge" warning gets changed a little as above; it's
> probably an old workspace and the most likely user action is to
> abandon the workspace too (or switch it to a new branch).  If the user
> is trying to revive the branch, they'll be explicit about what they're
> doing, like picking one head with -r.  Finally, if there are
> non-suspended heads, the 'all or nothing' rule doesn't apply, and
> nothing unusual should happen.

That sounds reasonable.  If you want to implement it, go ahead :).

Will          :-}