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

[David Allouche]

On Wed, Jun 09, 2004 at 09:45:12AM -0400, Aaron Bentley wrote:
> >REPLAY should check for the error _before_ it starts modifying the tree.
> 
> My rationale is that if the user does replay, they want the latest
> revision.  If replay can't produce the lastest revision, it should
> produce the latest revision that it can produce.  Users can then use
> 'update' to get the true latest revision.

The latest revision REPLAY can produce is generally useless to the user
who has been trying to update to the latest revision.

And it's generally a bad thing to modify the tree in a way which is not
always reversable when we are not sure to give the user what he wanted,
because that can pollute uncommitted changes.

I have a painful experience of having to do a lot of backtracking when
doing a merge with conflicts involving complex dependences.

> I think this is more consistent with the nature of replay.  (But then,
> I also think people shouldn't be using 'replay' as 'update'.)

It looks like some people only swear by "replay --skip-present" as a
merge operator. That's a perfectly reasonable use case. And in that
case, modifying the tree while the merge cannot be possible completed is
not a desirable behaviour.

> --no-sanity is underspecified since you didn't know about continuation 
> changesets.  One possibility is that it will apply continuation 
> changesets.  This makes it the same as --frankenstein.

Let me slightly reorder and update my proposal, in an attempt to clarify
the intent:

    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.

    REPLAY should check for the lineage 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-sanity, the patches will be applied immediately and an
    error will occur whenever the patch to apply belongs to a
    different lineage than the current tree (therefore it is weaker than
    --frankenstein).
    
Using --no-sanity, there will be no need for any additional network
operation in the common case because continuation revisions can be
indentified by examining the patchlog. There are currently three cases:

   * the patch is missing, it must be fetched anyway before
     application, so we have it handy to check wether it is a
     continuation

   * the patch is present, just check the tree patchlogs

   * the patch is missing but won't be applied because of
     --skip-present. We can only know the patch will not be applied
     after retreiving the patchlog with cat-archive-log anyway

> I'm no great fan of frankenstein-- I can't imagine why anyone would want 
> that.  But then, I couldn't imagine why anyone would want mixed versions 
> at first.  So I don't want to take away functionality that someone might 
> be using.

My point is that the REPLAY CLI provides a merge tool, and the merge is
only meaningful if all replayed patches belong to the same lineage.

Even if that is only a principled argument, I think it is strong enough
to warrant the inclusion of a significant finger-guard.

> All of this can be forced, of course, with replay --list.

Of course. That's the way to remove the finger-guard.

For the (prospective, unlikely) case where the logic of the
--frankenstein option would be needed, the desired behaviour can be
obtained using an explicit patch list and some scripting. I think that's
a good compromise between usability and functionality.


> >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.
> 
> How's that different from the above?

The error should occur before modifying the source tree. That was also
mentioned so my proposal is complete.

> >Alternatively, one can consider that TAG and IMPORT revisions are
> >associated to a simple changeset which just adds the patchlog.
> 
> TAG revisions *are* associated to simple changesets which just add the 
> patchlog.  IMPORT revisions are a hell of a lot more than that, but they 
> could be represented as changesets containing only new files.
> 
> >It would make sense since replay-reverse could then be used to remove
> >that patchlog. 
> 
> That works for continuations, because it reverse-applies a changeset 
> that really exists.  But not for import.
[...]
> Perhaps that's the case to be made for storing imports as changesets?

Nice to see that my line of thought is consistent with what tla already
does :-) Let me update my proposal:

    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
    is IMPORT revisions.
                                                                                
                     
    Suggestion for the error message:
                                                                                
                     
      replay does not make sense: revision has no changeset

    Alternatively, one can consider that 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.

Storing imports as full reversible changesets is not a good idea. That
would make IMPORT a slight variant of COMMIT which can work when there
is not history-previous revision. In particular, descendant imports (not
initial imports, that is) could not be distinguised from COMMIT
revisions.

> >In that case, JOIN-BRANCH becomes essentially obsolete.
> 
> It stops being obsolete again when commit --base is implemented.

I do not see what useful functionality would JOIN-BRANCH provide that
REPLAY cannot provide if imports are associated to trivial patchlog
changesets.

-- 
                                                            -- ddaa