Re: [Gnu-arch-users] Re: <<< conflict markers

[Aaron Bentley]

Tom Lord wrote:
> It pretends that the delta-patch version of `update' and the `replay
> --list' version of update are interchangeable.  But in fact, for mixed
> versions (mix of tags and commit) they can give different results.

Yes, and there are also some cases where replay would make a change and 
then undo it.  That can produce different results from delta.  Changeset 
composition anyone?

> `update', `star-merge', and a subset of `replay' are designed to "do
> the right thing" for purely commit-based versions.   If you're using
> mixed tag/commit versions, you have to role-your-own merge strategy.

So mixed versions are:
- really handy for advanced users
- easy to do by accident
- impossible to undo

Do I count as an advanced user?  Because I can tell you, as long as 
mixed versions aren't supported by the standard merge operations, I 
don't want to touch them.

>     > Okay, it sounds as if you actually want to support mixed
>     > versions.  Obviously, we can't Do The Right Thing for cases with
>     > no obvious right thing.  
>
> Right.  I wasn't too clear whether or not you recognized that,
> regarding mixed versions, there is no obvious right thing.

Well, I'm not sure I agree with you, but it seemed like we were getting 
unnecessarily stuck.

I always want update to do
undo
get --clobber $latest_revision
redo

As long as optimizations can be used safely, I'm in favour of them.

>     >  I
>     > always have or get the revisions in question, so it always does
>     > apply-delta.  In other cases, it does replay, correct?
>
> Correct.

But for all-tag versions, it does something that looks like delta.  Can 
we apply that to any tag-based revision?

You know, build-revision is just a fancy version of replay.  Maybe it 
would be better to get build-revision to apply its changes to the 
working directory.  I was planning on adding the ability to generate a 
revision from its same-archive sibling anyhow.

>     >> _Perhaps_ that should be fixed.
>
>     > Well, if you're not going to forbid it, I think ensuring
>     > consistent behaviour makes sense.
>
>
> Perhaps.  There's a trade-off in that ensuring consistent behavior
> means: (a) picking one of the two over the other (which one?) and (b)
> making `update' slower in some cases.

I think it's possible to keep the speed the same except for the cases 
where replay will do something demonstrably wrong.  I'm disappointed to 
see that libneon doesn't support pipelining.  If it did, we could 
actually make update faster.

> Unless there's a compelling utility for resolving the ambiguity in the
> meaning of `update' re mixed versions one way or the other, then the
> only reason to do it is to add "training wheels" and I tend to
> disfavor such changes.

Well, I'd have used it today if it didn't mean I had to roll my own 
merge strategy.  Instead, I bumped the version number.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.