gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: <<< conflict markers
Date: Fri, 16 Apr 2004 17:04:57 -0700 (PDT)

    A:
    >>> [mixed tag/commit versions vs. update]

    T:
    >> I understand you to be saying that `update' should better handle mixed
    >> versions _or_ mixed versions should be prohibited.

    A: 
    > Update in particular looks okay from the outside, using greedy revlibs. 
    > (I'm starting to suspect that it does the wrong thing if it has no 
    > access to the revisions in question.)

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.

    > Because of the tutorial's warning, I'm concerned that other operations 
    > will blow up, so I haven't used mixed versions.

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


    >> Prohibiting mixed versions is not an option.  They are quite useful.
    >> To choose an extreme example, in a version that exists only to be used
    >> with `get', they are clearly handy.

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


    > But there are levels of support, and a basic level of no
    > crashes, readable errors, and no destructive behaviour seems
    > like a reasonable target.  Perhaps we're there already.

At worst, I don't think we're far off from there already.

It's funny -- different design issues get reraised with different
frequency.   E.g., the structure of the namespace comes up every N
weeks.   I'd guess that the interaction of `update' and other merge
commands with mixed versions is an "every 6 months" issue.



    >> There is a bogosity I'm surprised you haven't brought up.
    >> Currently, the result produced by `update'
    >> _for_a_mixed_version_ is non-deterministic.  It depends on the
    >> state of your revision libraries.

    > I think the disconnect is due to my use of greedy libraries.  I
    > always have or get the revisions in question, so it always does
    > apply-delta.  In other cases, it does replay, correct?

Correct.


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

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.

-t






reply via email to

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