Matthew Sackman <[EMAIL PROTECTED]> writes: [...]
> Not just with the general disconnect operation either, but for > example, with policy branches: it may well be possible to prevent a > "code" branch being merged back into the main trunk or "release" > branch unless the "bug" branch corresponding to that code has no > open bugs. That kind of thing. I hope that there are some very cool > and useful possibilities that I've not thought of at all yet. Also true. Those could also be done by referencing bugids in certs, I suspect. As a concrete example, at work (not that anyone has any reason to care, but that's Isode Limited) we do almost all integrations only after code review. Code review involves a change report (a CR), which is just a text file that lists a bunch of things about the change, one of which is a list of bug ids, if this CR is fixing bugs. When the code's committed, the CR id ends up as part of the changelog. So when we prepare the release notes we can check to see which bugs may have changed status for that release (and then we can check bugzilla to see if they've been closed). So although just looking at bugzilla's not good enough (the bug may have been fixed only on a different branch), nevertheless we don't need to just rely on that. Using monotone, one could use a cert for the same purpose. (As an aside we keep these CRs under version control, and that provides (as far as I can tell, anyway) virtually no benefit in itself, in that we don't use branches for them and (as far as I know) nobody ever looks at previous versions of a CR. (That may be because of an implementation flaw, however: we don't store the to-be-reviewed code changes, and seeing changes in *that* might occasionally provide value.)) _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
