Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Open-source repository question



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

:-(



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links