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

[Tom Lord]

    > From: David Allouche <address@hidden>

    > I think we already have that "barrier of languages". 

Mostly.


    > Up to now, all that a user needed to know about star-merge was this
    > simple contract: merge related branches using that operator exclusively
    > and you will not have spurious conflicts. This contract is not
    > fulfilled. Either the contract or the tool needs fixing.

Not exaxctly, no.   Up to now, you have assumed that that was all a
user needed to know and the docs didn't go out of their way to point
out this case (because it hadn't come up and wasn't forseen).

Yet once it's explained, it makes perfect sense and changes nearly
nothing in terms of "best practices" (where that is interpreted to
mean "maximally useful effort giving constraints").

To a first approximation, the only bug is that the tutorial doesn't
contain a big cartouche surrounding a description of the trickiness of
concurrent commits.   Serious doc bug... absolutely.

I fully agree that that's a big documentation glitch but I also think
it's not that serious in absolute terms.  If you don't know what the
hell is actually happening when you run star-merge, and you hit this
undocumented case, sure --- you'll be confused.  But if you don't know
what the hell is actually happening when you run star-merge: then why
are you depending on it?  (To be clear: obviously *you* (and your
team) understand the issues just fine.)  If one *does* know what's
going on, then you wind up where *you* are: in want of a tool (if you
anticipate this coming up often) and alert to a doc fault.


    > No amount of rethoric can make a breach of contract into a user
    > error.

You misunderstood the contract.  Fair enough: it is commonly
unofficially summarized in a way that doesn't comment directly on this
issue.


    > > A proof that nobody can find a general solution is not much harder
    > > than the proof you have given for why star-merge isn't a general
    > > solution.  I don't have time ( :-) right now to write (again) such a
    > > proof myself but here's a hint: in addition to drawing merge diagrams,
    > > you might try adding some sample file contents.  It isn't that hard to
    > > construct examples of file contents for which automated merging in
    > > scenarios like this one is impossible unless the merge tool is an AI
    > > program that understands what the programmers are trying to do.

    > That would be a useful proof to have written down in public, since it
    > would demonstrate the need for a synchronisation protocol.

I'm sure there's a good (convincing) sketch of a proof in various
archives.  There are higher priorities, from my perspective, than this
one right now.


    > Whether such a synchronisation protocol can be reliably implemented in
    > software is another open question.

IMO, that's a site-specific issue.

    > I do not grok idempotent merging, 

It's a nice ideal, not really achievable in practice.   Only
approximations can actually exist in the real world.

    > but from what I gathered, there is a
    > solution to the problem which is not absolutely correct but whose
    > usefulness is comparable to diff/patch. Good enough for me.

    > But we still lack a proof that the problem cannot be solved using
    > technique which is a lower-hanging fruit than idempotent merge. 

I think it will be hard to find such a proof.  Rather, I think that,
with inventiveness, we can make ever-better approximations of
God's-idempotent-merge-command --- yet never converge on the real
thing.   It's all special cases from here on out.   (Think of it as
employment? :-)  (No, not really..... we'll cover 99.* percent in a
finite amount of time.)


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

    > The race condition cannot be avoided without imposing a real burden on
    > users. 

Sounds like a challenging problem.  Since, as I understand, yours is a
commercial effort, plus, yours is a problem not biting most users,
plus, your time constraints suggest you'll aim for a compromised
work-around that can be bested a little while later --- in g-a-u
context, as far as I'm concerned, .....  this is not the highest
priority.

Don't take your company's problems out on the community, please, even
if you suspect your company is good for the community.   And please
don't try to monopolize my attention.


Thanks,
-t


    [ignored due to time limits:]

    > Our pqm policy was updated: "do not merge from the pqm-managed
    > branch until you have received the failure or success message from pqm".
    > That policy is annoying and slows people down. It causes frustration,
    > and frustrated people make the world an unpleasant place to live in.
    > 
    > However, we can implement a merge operator which relies on one nice
    > property of pqm-managed branches: they only contain pure conflictless
    > merges. And I will write this merge operator in the next days. Unless,
    > of course, someone comes up with a more general solution.
    > 
    > -- 
    >                                                             -- ddaa
    > 
    > 
    > 
    > 
    > _______________________________________________
    > Gnu-arch-users mailing list
    > address@hidden
    > http://lists.gnu.org/mailman/listinfo/gnu-arch-users
    > 
    > GNU arch home page:
    > http://savannah.gnu.org/projects/gnu-arch/
    > 
    >