[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: <<< conflict markers
Date: Thu, 22 Apr 2004 17:19:02 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

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
get --clobber $latest_revision

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?


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 Bentley
Director of Technology
Panometrics, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]