[darcs-users] unique features + exponential time issue

[Petr Rockai]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> I would never use a merge tool that didn't signal a conflict in this
> case (and I'm pretty sure Darcs will, btw).  Even when, as in your
> example, the same developer has made both changes.  The chance that
> two independently made changes in adjacent lines interact semantically
> is way too high to be ignored.  Here's an amusing example (though
> perhaps not to the poor sod who finds the merged file and tries to
> debug it):
>
>   // This does all the work.
>   maybe_work ();
>   clean_up ();
>
> Now in branch A, we make a note:
>
>   // This does all the work.  FIXME: Sometimes it doesn't. bug #42.
>   maybe_work ();
>   clean_up ();
>
> and in branch B, we have a brainstorm:
>
>   // This does all the work.
>   quickly_and_serendipitously_correctly_work ();
>   clean_up ();
>
> You don't want to merge that, rather, pick B.
>
> Note that this is isomorphic to your "perfectly capable of a correct
> merge" example.

Yes, and i maintain that it is correct. Or you also maintain, that if
a merge tool cleanly merges following, you would never use it?

base:
// fooize the bars
void foo() {
   // ...
   wibblify();
}

branch a:
// fooize the bars; FIXME the wibblify call sometimes fails, why?
void foo() {
   // ...
   wibblify();
}

branch b:
// fooize the bars
void foo() {
   // ...
   if (wibblify_will_work())
       wibblify();
}

In other words, you are mixing up different problems, one that textual
merge cannot ensure correct semantic merge (and if you argue that a
case, where clean textual merge causes semantic mis-merge, is a bad
thing, then you should never use textual merge at all).

Also note, that the exact 3-way will probably handle the merge exactly
the same as darcs here, ie. no conflicts raised.

Yours, Peter.

PS: If it wasn't clear enough, the example in my previous post does
work with darcs as described, i have checked that before posting.

PPS: Just in case:

10:37:39 | morn at eri:~/tmp/testing -> diff3 -m a base b
// fooize the bars; FIXME the wibblify call sometimes fails, why?
void fooize() {
    // ...
    if (wibblify_will_work())
        wibblify();
}

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation