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

[Tom Lord]

    > From: David Allouche <address@hidden>

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

Yup.   We've occaisionally toyed with extending the patch-log
mechanism so that instead of just "present" or "absent" you could have
a third state for a log that means "not wanted" but it hasn't quite 
seemed to be a compelling need _yet_.


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

That's an interesting observation.

So we have some tree, we subtract out the latest revision, yet we want
to commit in such a way that that latest revision will show up in
later "whats-missing" calls.  --force will do that -- but not with
precision (it can bypass other changes in, for example, a shared
archive).

Now that I understand better what you meant, I would actually say
"border case" _and_ "asymmetry" or "border case representing an
asymmetry".

For the short term, I think the "fence revision" solution is a
perfectly fine solution.   This is a pretty rare case, after all.

But in the longer term, hmm..... I wonder if we don't want _four_
states for a log entry:

        1) applied  \ 
                     ... the current two states
        2) absent   /

        3) rejected  ... don't list in whats-missing, also not applied

        4) deferred  ... _do_ list in whats-missing, not applied, and
                         not enough to prevent a commit for not being
                         "up to date"

Logically, that's clearly sane.  Pragmatically, it might or might not
be overkill.

One fear though is that `deferred' would then turn into
`deferred-until-2005' and `deferred-until-the-zap-branch-is-merged'
and so on.   Where is the boundary between "bookkeeping arch should
do" and "bookkeeping that should happen externally"?


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

Not so sure.   It's not the math that's creating this asymmetry --
it's the "up-to-date" check before commit.   The choices seem to me
between living with this fairly obscure asymmetry and quite
complicating the meaning of "up-to-date".

It's an abstractly interesting case, though.

-t