Lapo Luchini wrote:
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")
Yes.
but the
database-behaviour of "disapprove" (a commit that reverts the previous
one), is that so?
I don't care much about the database behaviour. What I meant to say
earlier is that I'm happy with whatever choice the devs make. I only
really care about the workspace (not losing my work).
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 ;-)
Ok.
So I am clear, the entire command is "mtn db_kill_rev_locally" and
that's it? If we convinced the devs to make "mtn uncommit" an alias to
"mtn db_kill_rev_locally" would that cover my use case?
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 wouldn't try to uncommit if the changes had already been propagated.
Daniel.
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
