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

[Daniel Carosone]

On Sat, Jul 07, 2007 at 11:53:35AM -0700, William Uther wrote:
>    I'm busy scratching mtn itches.

Excellent.

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

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).

As a general rule from that, the "branch status descriptor" becomes
the union of the (trusted) status certs on all the (otherwise valid)
heads.  This is something that's created centrally and available
wherever needed, listed with a new ls variant, etc.

Then there's the interpretation and resulting behaviour for particular
values - such as hiding the branch name in 'ls branches' as you
propose for 'suspended'.

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.

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.

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

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.)

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

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.

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.

--
Dan.

pgpgNNM_pBPRV.pgp
Description: PGP signature