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

[David Allouche]

On Tue, Dec 09, 2003 at 02:21:00PM -0800, Tom Lord wrote:
>     > 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.
> 
> 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.

That seems sane logically, and I do not really see any other approach to
this problem, but that would also make some things a lot more complex.

Currently, one nice thing with Arch is that the patchlog semantics are
simple and clear. It's a mere matter of set arithmetic. Giving four
distinct states to patchlog would make things much more complicated.

Yes the more complicated solution could also be expressed in term of set
arithmetic (basically anything can) but that would require introducing
external invariants. For example you could have three sets: present,
rejected, deferred. But you would need the additionnal invariant that a
patchlog can be in at most one of those sets.

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

That's the point.

Currently rejection can be handled by including the patchlog and not the
changes. The description of the including changeset can say "rejected
patches foo and bar". Maybe adding extra headers for hypothetical
automated tools.

Deferral can be handled by removing the patchlog. My concern was that
this might interact with the merging tools in unexpected ways.

"deferred until never" is a project management problem, not something a
version control system has to concern itself with. The version control
can be used as a part of a project management solution, but it should
not attempt to superseed it.

That said, it might make sense, as a part of a broader change, to
address this problem and build explicit support for rejection and
deferral.

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

Agreed. Let us just keep that in mind. This might enligthen our approach
to future problems.

-- 
                                                            -- ddaa