monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: William Uther
Subject: Re: [Monotone-devel] RFC: 'suspend' certs
Date: Sat, 7 Jul 2007 19:53:40 -0700


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          :-}






reply via email to

[Prev in Thread] Current Thread [Next in Thread]