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

[David Allouche]

On Tue, Jun 08, 2004 at 01:59:51PM -0400, Aaron Bentley wrote:
> 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.

Good!

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

REPLAY should check for the error _before_ it starts modifying the tree.
This behavior should be only a feature of the CLI, not of the underlying
libtla command. For users who know what they are doing and want to save
the cost of the sanity checks, forward sanity checking could be disable
with a new --no-sanity option. 

With no argument or a VERSION argument, if there is a CONTINUATION
revision between the tree-revision and the last archived revision,
REPLAY should issue an error message and exit with failure.  The idea is
that REPLAY $VERSION is only useful within a given ancestry lineage, and
that CONTINUATION changesets changes the lineage.

Suggestion for the error message:

  replay does not make sense: version has a new continuation revision

REPLAY $REVISION is meant to apply an archived changeset. It should fail
with an error message if the specified revision has no associated
changeset (which is distinct from a null changeset). That includes
IMPORT and TAG revisions.

Suggestion for the error message:

  replay does not make sense: revision has no changeset

Alternatively, one can consider that TAG and IMPORT revisions are
associated to a simple changeset which just adds the patchlog. It would
make sense since replay-reverse could then be used to remove that
patchlog. In that case, JOIN-BRANCH becomes essentially obsolete.  That
is a bigger change, but I think it improves the consistence of the
command set.

The --frankenstein option is useless.

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

I do not think that STAR-MERGE is an issue. CONTINUATION changesets are
just a way to represent the history in a way which is more efficient and
useful. It does not affect the actual content of the trees.

Since STAR-MERGE is based on APPLY-DELTA, and is only concerned with
avoiding spurious conflicts, its functionality is not affected by the
way the history is represented.

-- 
                                                            -- ddaa