monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Justin Patrin
Subject: Re: [Monotone-devel] Approval revisited...
Date: Sat, 11 Feb 2006 15:12:37 -0800

On 2/11/06, Daniel Carosone <address@hidden> wrote:
> 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.
>

Ah, I see. Sorry, I thought Nathaniel was saying "revert -r REV" would
do the same thing as "disapprove -r REV". My mistake.

> 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".
>

I agree, connecting a disapprove to the revision it's disapproving
makes sense. Isn't this how disapprove works now? I could swear it
was....i.e. I had to disapprove, then merge, then update to get rid of
a revision somewhere up the tree.

--
Justin Patrin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]