Re: [Gnu-arch-users] Star-merge Fatally Wounded

[Zenaan Harkness]

On Sat, 2004-09-11 at 05:52, Tom Lord wrote:
>     > From: David Allouche <address@hidden>
> 
>     >         Merge scenario
> 
>     >         A-0 =====> B-0 
>     >          |          |
>     >          |          |
>     >         A-1 --  -- B-1  
>     >          |    \/    |
>     >          |    /\    |
>     >         A-2 <-  -> B-2
> 
> 
> [Nicely lucid message and elegant proof, by the way.  Thanks for
>  taking the time.]
> 
> Abentley's short answer sums it up nicely:
> 
>   To put it another way, star-merge works when one revision from
>   REFERENCE or OTHER is the most recent merge.  When merges happen in
>   parallel, there is no most recent merge, and the algorithm breaks.
> 
> Although I disagree with some of the rest (see below).
> 
> This reply is a bit long.   You touched on an interesting topic.
> 
> I believe that what you have in that scenario (since you are planning
> on using star-merge and maintaining a star topology) is, alas, a user
> error.  But let me explan and qualify that and ack that you do have a
> real technical problem that needs attention and make a few suggestions
> about how to solve it.
> 
> Here's the user error:  Which existed first?  A-2 or B-2?   
> 
> Without loss of generality, let's assume that A-2 existed first.
> 
> Then B-2 was created, *in effect*, by:
> 
>       % tla get B-1 
>         % cd B-1
>         % tla star-merge A-1          [***]
>         % tla commit
> 
> The [***] step is the "user error" because, at that time, A-1 is not
> the latest revision.  A-2 was the latest revision (in the absolute
> scheme of things) when that merge was done.

> Short answer, for your immediate needs: if I were you, I'd first try
> to eliminate the race conditions in your merges.  Either your
> infrastructure should never attempt a "[***]" merge (described above)
> or else your infrastructure should have an exception handler to
> recover from this case.
> 
> I'm a *tiny* bit concerned about the scenario because it is something
> that can easily happen quite by accident.   For example, it could
> happen between my and jblack's tla branches if the timing of our
> mutual merges and mirror pushes worked out that way.    I'm only a
> tiny bit concerned because that doesn't seem to be that likely;  the
> mildly attententive programmer will notice it if it does;  and it
> doesn't seem that hard to recover from by-hand.   Still.... it is at
> least a very interesting note to keep in mind for process design.
> 
> Abentley proposes:
> 
>   The star-merge command should be updated to detect this situation
>   and error-out when it occurs.  This can be done by determining
>   LAST_MERGE_INTO_REFERENCE, comparing it with MAYBE_ANCESTOR_2, and
>   determining ANCESTOR'.  If ANCESTOR' is not ANCESTOR, then there is
>   no valid ANCESTOR.
> 
> I don't believe that, what with mirrors and all, the star-merge
> command can reliably detect this situation.   star-merge is operating
> under a condition of "imperfect information", no matter what.
> 
> Consequently, what you (Abentley) propose is to take the very regular
> behavior of a command, add an arbitrary exception, and that exception
> doesn't really solve the problem.  I'd rather have the regular command
> without the hairy yet imperfect exceptions.  That's easier and simpler
> and: hey -- programming tools are intrinsicly dangerous in the first
> place: you're not going to solve *that* no matter how many little
> quirks you add to them.

ABentley (or whoever), I'll happily use a wrapper adding such hair for
the little extra fool proofing, if it's possible.

>From my memory of Bitkeeper's functionality, it errors out with a
message to "pull first, then push again" or something... I could be
mixing up scenarios though...

TIA if anyone implements such
Zenaan



> Relevent quotes: 
>   "If you can't stand the heat...." 
>   and
>   "Doctor, it hurts when I do *this*....."

Well, we don't really need hand brakes on cars either, since if
you're parked facing uphill, put it in a forward gear, and if parked
facing downhill, park in reverse... of course, some people might
occasionally forget which gear is needed, car insurance (undo)
notwithstanding...

:)