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