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

[Aaron Bentley]

David Allouche wrote:
(mucking with the order here...)

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

Except for imports, all revisions contain changesets.  If only simple 
revisions had changesets, I wouldn't be worried about replay vs mixed 
versions.

The changeset produced by tag just adds a patchlog.  A changeset 
produced by commit --base would, obviously, be more complex, but the 
basic structure is identical.

Even imports could be expressed efficiently as changesets, though I'm 
not sure there are any advantages to that kind of regularity.


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

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.  I think this is more 
consistent with the nature of replay.  (But then, I also think people 
shouldn't be using 'replay' as 'update'.)

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

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

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.

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

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

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

address@hidden:~/release$ tla replay --reverse 
address@hidden/engine--release--7.6.3--base-0
Failed to open files: 
/mnt/arch/development/engine/engine--release/engine--release--7.6.3/base-0/engine--release--7.6.3--base-0.patches.tar.gz
address@hidden:~/release$
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error exit delayed from previous errors

Perhaps that's the case to be made for storing imports as changesets?

> In that case, JOIN-BRANCH becomes essentially obsolete.

It stops being obsolete again when commit --base is implemented.

Aaron