Re: [tlug] Open-source repository question

[John Fremlin <john@example.com>]

Stephen J. Turnbull wrote:
> John Fremlin writes:
>  > For a slightly contrived way of making the original darcs blow up, you 
>  > could have:
>
> Sure, but this "contrived sequence of patches" also "blows up" the
> current heuristic that identical hunks don't conflict.

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.

>  > It's not relevant to the theory at all, it's just a decision of the 
>  > conflict black box.
>
> If you need an oracle for conflicts, you don't really have a patch
> theory at all.  In fact the published theory (such as it is) does have
> criteria for conflict in it, and the theorems about commutation are
> specific to those criteria.  You cannot put just any "black box" into
> the "patch theory" appendix or into "camp" (AIUI) and derive a new VCS
> as a corollary.

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

Sorry if I wasn't clear enough when I tried to explain this before.

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.

As another example, given a valid conflict oracle that works considering 
files to be lists of lines, you could construct another valid oracle 
that works the same way but considers files to be a list of words.

On the other hand a conflict oracle that determined whether two patches 
conflicted based on the last bit of the checksum of the two patches 
xor'd together would be consistent on any pair of patches, but would not 
meet the necessary requirements for treating patch decompositions 
consistently.

>  > > 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 ;-)
[...]
> But in fact git only does that in certain circumstances.  Normally it
> will try to merge, which requires detecting conflicts, and marking
> them if they're found.  Darcs just tries harder to avoid conflicts.

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.

>  > You claim that git is Turing complete?
>
> No, I said it was a specialization....

:-(