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

[David Allouche]

On Mon, Dec 08, 2003 at 08:11:46AM -0800, Tom Lord wrote:
> 
>     > From: David Allouche <address@hidden>
> 
>     > 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.

Ok. Thanks for reminding the basics.

Essentially, "remove the patchlog" means "I do not want that patch in my
tree now, but it should be reintegrated later", and "keep patchlog"
means "hey, that was stupid and/or no longer necessary, just forget
about it".

Though I am a bit unsure about it. If I make an original change in
revision P of version V, then replay-reverse that change in revision Q,
the last revision of V will no have the patchlog of P. That means that
whats-missing from version V in version W will say Q but not P. But
since you need to have applied P in order to apply Q, you may run into
trouble with "replay --missing". Also, P will end up never showing in
whats-missing listings for anyone who do not get out of its way.

What will be the effect on star-merge? I guess there is no difference.
Or maybe not, depending on the context...


>     > 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".

I have a very familiar feeling (with other people I work with) that we
are starting to talk about different things. I acknowledge what you are
saying about keeping or not the pathchlogs, but there is still an
issue. That's like hitting a nail which sticks out of one side of a
partition.  That will just make it stick out on the other side.

If we keep your perspective that "replay --exact --reverse; sync-tree"
is natural though a bit verbose, the problem becomes that when you
"replay --exact --reverse" the last changeset, you tree gets in the same
state as if you had undone the last revision (or if someone else just
concurrently commited a new revision). That is to say, you get a tree
you cannot commit (maybe you can commit it with --force, but that is a
bad thing to do anyway on concurrently used archives).

Actually, that is a border case, not an asymmetry. I guess the proper
way to "reverse and remove the patchlog" for the last revision involves
creating an empty revision to serve as a fence. That would be a wart,
wouldn't it? Call it "emergent property of the math" if you want.

still think that needing to create an empty revision to be able to
accomplish a reasonable task should be considered a symptom that the
math needs improving.

I guess when I have a change I need to back-out at once but do not want
to forget, I would be better off using a separate branch... That's
another way of moving the problem: no point in hitting the nail, it is a
screw.

-- 
                                                            -- ddaa