Nathaniel Smith <[EMAIL PROTECTED]> 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? As I said, the new child would be a head, and I regard that as a feature: some of the time, we decice that a proposed change is good, but not now. In that case, I'm imagining we could mark the head with one of these certs, and also tag it so we could easily find it in the future, and then do an explicit_merge. Or (depending on implementation), just add a branch cert to make it a head of a new branch. That also strikes me as generally useful: you fork a branch, but after a couple of revisions decide that work would be better in its own branch. This might allow you to do that (presuming everyone cooperates, or (I guess more likely) this all happens before you sync). I can understand why someone might not see the need. If you're coming from CVS or subversion or something similar, then you'd be used to just committing things and fixing them in place. However, reviewing before integration isn't that unusual. Aegis is an obvious example, but GNU Arch people seem to work similarly: someone develops in their archive, and when they've got something they think is worth merging they say so, and the central coordinator merges the patches (presumably after looking at them). I guess what I'm suggesting is not unlike accept_testresult_change, although I read that as only applying to update (whereas I'd want it to apply to merge and propagate, too). [...] _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel