Re: [Gnu-arch-users] Re: How to back out a change

[Tom Lord]

    > 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