Re: [Monotone-devel] Approval revisited...

[Daniel Carosone]

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.

pgpcWoxIwpLMu.pgp
Description: PGP signature