Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

John Fremlin writes:

 > Correct, the point was that by splitting the example into patches in a 
 > different way causes the original problem you described to appear in 
 > both versions, so that in some sense they are equal.

Sure, in the sense that since 1 != 0 and 2 != 0, 1 == 2.  The original
Darcs was "more correct" according to those test cases, and there is
no way that a text-only merge can detect the second case so all
existing VCSes (except the "many eyes" merge algorithm :-) fail it
too.

So you're back to Curt's contention that you have to check every merge
as if it were a patch submitted by the black hats.  Which may work in
his shop, but it sure as hell doesn't work in any of XEmacs, Emacs,
Gentoo, Debian, Ubuntu, bzr (!), Darcs (!), MacPorts, or X.org, all of
which regularly release total brain farts so they're not checking
anything, let alone merges.

 > Yes. However, I think both of the patch conflict systems satisfy
 > all the reasonably necessary axioms for the conflict oracle (are
 > these articulated anywhere?).

I don't think anything text-based can if it doesn't satisfy "two
patches that touch the same text conflict unless they are identical
across the whole extent of the patch."  And no, I haven't seen them
articulated anywhere for VCSes.  Maybe they're in camp.  I have been
told there's been work to get them articulated for concurrent text
editing, but that's a different can of worms in some sense.

 > For example, with reasonable axioms, it would be trivial to show that 
 > given a valid conflict oracle that considers upper and lowercase to be 
 > different, you could make a new one that does not consider upper and 
 > lowercase to be different.

But that inference would be wrong for almost everything except Lisp
and BASIC.  So I don't know what you mean by "could make a new one".

 > Yes, that's what I call "worrying". Maybe it's the wrong word. For 
 > example, I would say that a virus checker "worries" about whether or not 
 > an executable is safe, whereas a system like SELinux doesn't worry.

I agree, and I don't think it's the wrong word.  git does indeed worry
in that sense, and in fact you can choose how much git should worry
(the --strategy option to commands that might perform a merge.