[Top][All Lists]
[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
- Re: [Monotone-devel] Approval revisited..., (continued)
- Re: [Monotone-devel] Approval revisited..., Richard Levitte - VMS Whacker, 2006/02/10
- Re: [Monotone-devel] Approval revisited..., Timothy Brownawell, 2006/02/10
- Re: [Monotone-devel] Approval revisited..., Richard Levitte - VMS Whacker, 2006/02/10
- Re: [Monotone-devel] Approval revisited..., Timothy Brownawell, 2006/02/10
- Re: [Monotone-devel] Approval revisited..., Daniel Carosone, 2006/02/10
- Re: [Monotone-devel] Approval revisited..., Richard Levitte - VMS Whacker, 2006/02/10
- Re: [Monotone-devel] Approval revisited..., Bruce Stephens, 2006/02/10
Re: [Monotone-devel] Approval revisited..., Nathaniel Smith, 2006/02/11
Re: [Monotone-devel] Approval revisited..., Nathaniel Smith, 2006/02/11
[Monotone-devel] Re: Approval revisited..., Bruce Stephens, 2006/02/12