On Sun, 2005-06-05 at 17:53 -0400, Michael Stone wrote: > I'm attempting to give people a clean way to mark a revision as > "no-longer-a-head-for-branch-X". There are two use cases for a feature > like this one: > > 1) To ignore old branches which have subsequently been merged into the > mainline. > 2) To mark revisions as unsuitable for merging.
(2) seems like an obvious meaning of such a cert. > However, it is unclear whether these use cases should be combined or > should be handled separately. In discussions on IRC, we decided to try > to implement at least the first case with a new certificate type, > tentatively named a "prune-branch" certificate by dscherger. The > functionality is currently implemented by modifying the > get_branch_heads() function in cert.cc. I'd say combined, with (1) being the special case that all heads are pruned. > Algorithmically speaking the changes is from the present: > Find all revisions with branch certs with value X. > Remove revisions which are ancestors. > > to the new: > Find all revisions with branch certs with value X. > Remove revisions which are ancestors. > Find all prune-branch certs with value X. > For each revision, discard if it has an attached prune-branch cert. > > Applying prune-branch certs is easy: you just run > monotone cert REVID prune-branch BRANCH. > > Two questions remain: > How should the selection of update targets behave in the presence of > prune-branch certs? Only automatically choose a rev that isn't pruned from the branch in question. > How should this certificate affect commands which rely on the old > behavior of get_branch_heads()? I'd think the new behavior would be good for all of them. Tim _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
