Re: [tlug] Open-source repository question

[John Fremlin <john@example.com>]

Stephen J. Turnbull wrote:
> John Fremlin writes:
>  > Stephen J. Turnbull wrote:
>
>  > > The assumption that two changes which conflict partially but are
>  > > identical on the conflict are not in conflict.  David originally had
>  > > this right but eventually bowed to pressure from the peanut gallery.
>  > 
>  > Why do you think one way is more correct than another and how does this 
>  > relate at all to the theory?
>
> The problem is precisely that *neither* way is globally correct;  you
> need to understand the semantics to know which answer is right.

Yes, I agree, I was wondering how you squared that with your peanut 
gallery pressure comment -- your example below is great.

[...]
> OK, so let's merge.  I insert at line 2, you insert at line 4, no
> conflict, right?  And semantically, entirely reasonable, no?  But we
> both changed line 6, in the same way.  Original Darcs would throw a
> conflict on that ... and be right.  'Cause now we get:
>
> --------------------------------
> char *identifiers[25] = {
>     "char",
>     "double",
>     "float",
>     "int",
>     };
>
> int next_open_slot = 3;

For a slightly contrived way of making the original darcs blow up, you 
could have:

PATCH 1: reserve new slot
- int next_open_slot = 2;
+ int next_open_slot = 3;

PATCH 2a: add char id
+ "char"

PATCH 2b: add int id
+ "int"

so that it would think that 1+2a would not clash with 1+2b, because they 
are both based on patch 1, giving the same problem.

I admit this is contrived and I suppose it is all a question of what is 
more likely to happen in practice.

I would suspect that the peanut gallery is correct here, in that it is 
more likely for anonymous shared subpatches not to conflict so the extra 
conflict messages are an annoyance.

>  > The theory works fine provided the black box that determines whether 
>  > patches conflict is "reasonable" -- I'm not sure of the exact conditions 
>  > -- are you saying they are violated by this the choice of allowing 
>  > patches that share a common implied patch to commute or not?
>
> I'm saying that there is a theory which says two patches which change
> the same place are in conflict, unless the wholes of the two patches
> are identical, and Darcs followed that theory at first, but then
> decided to go with the heuristic that this is usually something like
> the typo case.

It's not relevant to the theory at all, it's just a decision of the 
conflict black box.

>  > I don't see this at all, sorry for being so slow -- can you explain?
>  > 
>  > On a related note http://projects.haskell.org/camp/
>
> Yeah, I haven't been following that, they decided to go their own way
> and not publish on the Darcs lists.  But the occasional traffic on the
> Darcs list suggests that camp is no better in the sense that it has no
> semantic theory, and is entirely based on textual heuristics for
> identifying conflicts.

Yes.

>  > > Of course git has to worry about conflicts.  If it didn't, there would
>  > > be no need for git-rebase --continue and/or git-rebase --skip.
>  > 
>  > It doesn't worry about it, it let's the users deal with it and provides 
>  > tools to help them.
>  > 
>  > Darcs is explicitly designed to worry about it.
>
> No, it's not.  Darcs is designed to be smarter about what is and isn't
> a conflict, but if it detects a conflict, Darcs throws the whole thing
> into the user's lap just like all the others.  And in fact I don't
> think Darcs really does much better than the heuristics build into git
> (like "patches which don't touch the same file don't conflict").

It doesn't do better we I think we agree. You call it being "smarter" I 
call it "worrying" but it seems to amount to the same thing ;-)

>  > As the H.264 stuff used DMA, these two changes had to have separate 
>  > branches (in fact as we used CVS, I actually just checked out versions 
>  > of the source tree into different directories).
>
> But this is precisely what Curt advocates, no?  Keeping it in a
> workspace until it's ready to go into the mainline.  The point of a
> branch is communicating (either with other developers or a forgetful
> incarnation of yourself :-).  So I'm not sure where you're going with
> this (unless you meant you *wished* you could branch but you were
> stuck with CVS...).

Yes, we couldn't easily branch because of CVS so we sort of checked in 
as much as we could and then emailed the extra stuff about.

>  > You could equally well claim that git was a specialised Python.
>
> Well, you can claim that anything is a specialized Turing machine,
> too.  But in the Lisp analogy there's something a little deeper than
> that going on, I think.

You claim that git is Turing complete? (I.e., how can you use git to 
compute?) I guess you could do it by playing with the hooks, but that is 
a bit of a stretch. . .

PS. http://www.roytanck.com/2008/11/06/sudoku-solver/