[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: How to back out a change
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Re: How to back out a change |
Date: |
Mon, 8 Dec 2003 08:11:46 -0800 (PST) |
> From: David Allouche <address@hidden>
> Mhh... just a question while we are at it.
> Is is "correct" (it the sense that the various merge tools will
> behave appropriately) to back-out a change which is not the
> latest revision (but, say, the one-to-last revision) with replay
> --exact --reverse?
That will remove the log files for the old revision which is sometimes
what you want and other times not.
Do you want the old (removed) revision to appear in `whats-missing'?
Do you want an (ordinary use of) `replay' to try to put it back?
That will be the effect of `replay --exact --reverse'.
On the other hand, if you want to leave the logs, you have to take two
steps (and, yes, these will be combined in a single convenience
command at some point but):
tla replay --exact --reverse <patch-to-remove>
tla sync-tree `tla tree-version`
the second command puts back the logs (but not the changes) removed
by the replay.
> That seems the natural way to do it (and for Florian too, it
> seems). But there is clearly an asymmetry with the tree-sync
> trick to back-out the last change: with replay --exact --reverse
> the patchlog for the backed-out change is removed.
Well, let's suppose that you want to undo the very latest revision,
patch-N. You could:
tla get proj--branch--1.0--patch-<N-1> dir
cd dir
tla sync-tree proj--branch--1.0--patch-N
but notice that
tla get proj--branch--1.0--patch-<N-1>
cd dir
has the same effect as:
tla get proj--branch--1.0--patch-N dir
cd dir
tla replay --exact --reverse proj--branch--1.0--patch-N
so, really, these are the same technique. The "asymmetry" is just
because there's a short-cut for getting a tree in which the latest K
patches have been removed (namely by getting the Kth-from-latest
revision).
> Should that asymmetry be considered a mere wart, to be fixed one
> day when someone get the right idea, or is it a symptom of a
> wider problem?
It's not even a wart -- it's just an emergent property of the math.
Just like "multiply a decimal number by 10" is an easy special case,
"undo the latest K changes" is an easy special case.
The wart isn't that -- but is that you have to do the sync-tree in a
separate step. It's a common-enough case that it shouldn't be
required. And, in fact, all of the merge commands should have an
option that means "don't change the log files".
-t