[darcs-users] Conflict marking

[Stephen J. Turnbull]

>>>>> "Richard" == Richard A Smith <rsmith at bitworks-inc.com> writes:

    Richard> When merging patches from other peoples repos its
    Richard> information thats really useful.  Last week I was pulling
    Richard> in some patches in the master repo and a had a confict.
    Richard> I knew that I had changed the file in questions and that
    Richard> my copy was the best one to use.

    Richard> So when I went to look at the file I found myself unable
    Richard> to remember exactly what it was that I had done that made
    Richard> my version better.

Well, *I* would say that's a strong indication that the code needs
review (only half-joking).  I agree that *darcs* shouldn't second-
guess you, though, it should give you all the information it has.

Unfortunately, it's not obvious how to present it right.  To give a
slightly contrived example, suppose we have a rollback at a certain
line, but the patch as a whole is _not_ a rollback.  Ie, the current
state of the mainline repository *at that line* is

    Original + P1 - P1 + P3 == Original + P3

but Darcs has recorded it as

    Original + P1 + P2 + P3

while the state of your workspace is

    Original + P4

Now in the Darcs way of thinking[*], P4 conflicts with *all* of P1,
P2, and P3, even though you and I know very well that P2 = inv(P1) and
the *real* conflict is P3 vs. P4.

Probably this can be untangled, but it's not obvious what the general
principle should be.

This is really a symptom of the fact that the theory of patches is in
its infancy.  If you can be patient, though, a stronger theory is
currently under development and in fact the developers just did a
"conflictor sprint" at a conference (see Ian Lynagh's recent post on
darcs-conflicts for details).

[*] This is counter-intuitive to developers coming from a CVS (or
similar) background where a patch that produces identical text to the
existing text is *not* a conflict.  *This is a bug*, for example in
the case where the intended semantics of the patch is "increment the
number on this line".  If two independent patches result in the same
number, then one of them has failed to increment the number.


-- 
Graduate School of Systems and Information Engineering   University of Tsukuba
http://turnbull.sk.tsukuba.ac.jp/        Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
        Economics of Information Communication and Computation Systems
          Experimental Economics, Microeconomic Theory, Game Theory