On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote: > > Personally, I think the functionality of 'disapprove' should move to > > 'revert' ('revert -r REV [RESTRICTION]; commit'), and 'approve' could > > just go away, or stay on until we have a real story, or whatever. > > The name 'revert' of course makes sense for this, but this will also > clash with the 'revert' used to revert a change in a working copy....
This is exactly the same command. Notice the -r REV, which means to revert the [RESTRICTION] files to as they were in REV (as opposed to the BASE rev as default), and a commit after. Thus a revert is just like an update that doesn't change MT/revision, so diffs and commits are still relative to the original BASE. This works fine if your BASE is the revision where the 'bad' change was first made, or at least some near descendent before other changes have been made in the relevant files too. If intervening changes have been made, the current functionality of 'disapprove' is to apply a reverse patch against the current head. That's handy and convenient, but I actually think the more appropriate way to achieve this is to actually go back up the graph and checkout the original damaged BASE rev, revert and commit as above, and then merge the new head with the anti-change with the current head. The resulting graph just makes more sense: it connects the bad change with the repair, and shows you the alternate path in between that's affected by the bad code. So, "yes please". -- Dan.
pgp7ojUvMs3r0.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel