monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: Undo a commit


From: Lapo Luchini
Subject: [Monotone-devel] Re: Undo a commit
Date: Fri, 10 Oct 2008 02:04:02 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.0

Daniel Carrera wrote:
> So I don't blame "mtn update" for changing the files. I think that the
> problem is with "mtn disapprove"

But actually "disapprove" is not meant to be an "un-commit", it is meant
to mean "hey, that patch that some guy landed in the main branch is
*BAD*, it breaks thing, I don't want it, I want to back that out".

In this context, I think what it does is what should be done... OTOH I
never ever used disapprove myself so, not having real use-cases at hand,
my opinion count less than yours ;-)
(monotone developement has been historically very use-case-driven)

> I'm not sure that I agree that the problem is that there is no un-commit
> with Monotone. I don't object to Monotone recording the fact that I made
> a wrong commit and decided to reverse it. I only object to not being
> able to do the correct commit later.

So what you actually needed was something that had the
workspace-behaviour of "db kill_rev_locally" (i.e. putting the workspace
"just like it was a second before previous commit") but the
database-behaviour of "disapprove" (a commit that reverts the previous
one), is that so?

> This is how I was expecting "mtn disapprove" to work:
> 
> mtn commit
> 
> ## Oops, I commited Foo and Bar but I only meant to commit Foo.
> 
> mtn disapprove  ## A commit that says "cancel the last commit".
> 
> mtn commit ## THIS time I get only Foo like I originally intended.

IMHO in this use-case what you want to use is *REALLY* the good old
"db kill_rev_locally". It is meant exactly for *that* (un-committing
something *just after* it was committed by error).

Or at least, that what I do in those (quite frequent) cases I do a wrong
commit ;-)

If your "wrong commit" was already propagated on other servers, it's
more complex (as you should track them all down), so it's probably
better to disapprove and manually reconstruct the workspace state (e.g.
NOT updating to the "disapprove"-generated revision but instead changing
_MTN/options to just *be* that revision while keeping the content of the
disapproved commit).
(yes, I do agree having to edit _MTN/options manually is not the
cleanest solution, but OTOH wanting to revert something big and
synchronized elsewhere while at the same time having an old workspace is
not a very clean problem by itself, probably... but I guess this is
quite the area of "patches with improved functionality are very welcome,
given they have a decent UI and don't break other uses")

-- 
Lapo Luchini - http://lapo.it/

“Violence is the last refuge of the incompetent.” (Isaac Asimov,
"Foundation", 1942-05)





reply via email to

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