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

[Aaron Bentley]

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.

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.

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.

Did I forget anything?

Aaron
David Allouche wrote:

>   
>   -- tag-in-version are still not really useful for common usage, but
>      they can be useful as a temporary workaround until "commit
>      --continuation" is restored
>
>   -- tag-in-version are simple cases of continuation changesets, if the
>      various merge tools are fixed to behave sanely in the face of
>      continuation changesets, then they will also behave sanely in the
>      face of tag-in-versions
>
> Bugs should be fixed.

--
Aaron Bentley
Director of Technology
Panometrics, Inc.