[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG] Fix merge commands to behave sanely for mixed
Re: [Gnu-arch-users] [BUG] Fix merge commands to behave sanely for mixed versions
Mon, 14 Jun 2004 17:42:24 -0400
Mozilla Thunderbird 0.5 (X11/20040309)
Tom Lord wrote:
> From: Aaron Bentley <address@hidden>
> Therefore, update shall
> scan the revision types before beginning, and fall back to the
> apply-delta strategy if replay cannot be used safely.
At the same time, please add to archive.c to cache revision-type
information so that this change does not increase the number of
AFAICT, replay does not currently scan revision types, so it will slow
down the case where the replay strategy can safely be applied. The scan
won't happen for the case where apply-delta is currently chosen. So
caching will only help the case where replay would normally be selected,
but the scan determines this is unsafe.
I'm still in favour of it, but I don't think it'll help much.
> 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.
No. I regard
as just shorthand for
replay VERSION--patch-X VERSION--patch-Y ....
so I don't like adding in some arbitrary restriction.
As the name --frankenstein implies, replay across continuations will
produce a composite that contains the changes from several distinct
lines of ancestry. It will probably result in conflicts, especially if
the continuation is produced by commit --base.
I think that behaviour will almost never be useful.
OTOH, skipping continuation revisions would interact very nicely with
commit --base. It would be especially nice if there were no actual tree
changes in the continuation commit (aside from the patchlog).
> 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.
No. It needs a "--ancestor REV" option, to be sure.
I'm not sure what you mean this option to do. If that specifies the
specific ancestor to use, there's no difference between
star-merge --ancestor A B
apply-delta A B
It _maybe_ needs some options that, like --reference, tweak the
ancestor selection algorithm.
Well, if the only support was a --use-patchlog-ancestry option, that
would be adequate to me.
But picking the ancestor based on patch-log contents is pretty
fundamental to arch. It's predictable and fast and it does not
require knowledge of the ancestry of the YOURS and MINE trees (hence,
fewer roundtrips, etc.).
The patchlogs contain ancestry information as well merge information, so
there's no need for more round trips. It should be very easy to use the
"Continuation-of" header to exclude namespace-previous revisions that
aren't actually ancestors. The behavioural change is that star-merge
would report "cannot merge unrelated trees" slightly more often, instead
of doing ill-advised merges in those cases.
It's pretty fundamental that ancestry is generally _not_ the basis of
merge commands in arch.
That's not intuitive. In fact, the star-merge documentation
consistently refers to finding an "ancestor". It seems like a bug
to me that very occasionally it may pick an "ancestor" that is
not, in fact, an ancestor.
Yes, that means you can do weird things
like replay the changeset found in a continuation but (a) that's
useful and (b) the alternative is worse, all around.
I haven't proposed preventing replay from applying continuation
changesets, just preventing it from doing so automatically.
And really, I don't care about fixing replay. I'm happy to let people
who use replay VERSION suffer, because I think they're doing it wrong.
If we can prevent star-merge from doing the wrong thing, then I think
we'll have a solution.
Director of Technology