Re: [Gnu-arch-users] [BUG] Fix merge commands to behave sanely for mixed versions

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > severity: wishlist

    > Update: Update's apply-delta strategy is sound.  Its replay strategy 
    > only works for the case where there are only simple revisions between 
    > the current revision and the target revision.  Therefore, update shall 
    > scan the revision types before beginning, and fall back to the 
    > apply-delta strategy if replay cannot be used safely.

This is correct.  It simply fixes a bug in update which should never
produce a result that would not have been produced by the apply-delta
strategy.

At the same time, please add to archive.c to cache revision-type
information so that this change does not increase the number of
roundtrips.




    > Replay: Replay VERSION is sometimes used as a faster 'update', but is 
    > actually a lower-level command.  However, there's very little sense in 
    > applying a continuation (e.g. tag) revision to a tree containing a 
    > namespace-previous revision.  Therefore, replay VERSION shall apply only 
    > simple revisions, and stop processing at the first non-simple revision 
    > it encounters, unless passed the new "--frankenstein" option.  Replay 
    > REVISION shall have no such safeguards.

No.   I regard

        replay VERSION

as just shorthand for

        replay VERSION--patch-X VERSION--patch-Y ....

so I don't like adding in some arbitrary restriction.


    > Star-merge: Star-merge's common-ancestor selection algorithm may ignore 
    > the fact that a version contains unrelated revisions.  If this is the 
    > case, it should be updated to consider only related revisions.

No.   It needs a "--ancestor REV" option, to be sure.

It _maybe_ needs some options that, like --reference, tweak the
ancestor selection algorithm.

But picking the ancestor based on patch-log contents is pretty
fundamental to arch.  It's predictable and fast and it does not
require knowledge of the ancestry of the YOURS and MINE trees (hence,
fewer roundtrips, etc.).

It's pretty fundamental that ancestry is generally _not_ the basis of
merge commands in arch.   Yes, that means you can do weird things
like replay the changeset found in a continuation but (a) that's
useful and (b) the alternative is worse, all around.

-t