You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2005/08/10 18:46:37 UTC
Mismerge case
In http://lists.zooko.com/pipermail/revctrl/2005-August/000049.html,
zooko identified a mismerge case with Subversion. I'll append the
three files below.
The case is perhaps a little unfair to Subversion, because it relies
on a situation where Subversion's internal diff produces a funny (but
valid) diff between ancestor and target1:
--- init (.../init) (revision 1)
+++ init (.../1) (revision 1)
@@ -1,5 +1,10 @@
-int square(int x) {
+int fast_square(int x) {
int y = x;
+ return y * x;
+}
+
+int slow_square(int x) {
+ int y = x;
for (int i = 0; i < x; i++) y += x;
return y;
}
while gnu diff happens to produce a more natural diff. However, I
think it's also the case that diff3 requires some unmodified context
between changed lines in order to perform a clean merge, and we are
not requiring any context, which is kind of unsafe. Can anyone more
knowledgeable about libsvn_diff speak to that?
--- Ancestor ---
int square(int x) {
int y = x;
for (int i = 0; i < x; i++) y += x;
return y;
}
----------------
--- Target 1 ---
int fast_square(int x) {
int y = x;
return y * x;
}
int slow_square(int x) {
int y = x;
for (int i = 0; i < x; i++) y += x;
return y;
}
----------------
--- Target 2 ---
int square(int x) {
int y = 0;
for (int i = 0; i < x; i++) y += x;
return y;
}
----------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mismerge case
Posted by David Weintraub <qa...@gmail.com>.
Both ClearCase and Perforce are known for their excellent merge
capabilities and I believe neither are based upon diff or gnu diff. I
wonder how these two tools would handle this situation?
On 8/10/05, Greg Hudson <gh...@mit.edu> wrote:
> On Wed, 2005-08-10 at 21:36 +0100, Philip Martin wrote:
> > How many of those merge tools are built on top of GNU diff?
>
> >From what I can tell:
>
> * diff3 is part of diff, so obviously generates a conflict.
>
> * CVS merging is built on top of gnu diff, so obviously generates a
> conflict.
>
> * "merge" is part of RCS, so might be independent from gnu dif, and
> generates a conflict.
>
> * pcdv merge (Codeville's new merge algorithm) generates a conflict
> because it requires one line of context.
>
> * darcs generates a correct merge (because it's lucky). This was a
> bit of a surprise to zooko, who thought that darcs would generate a
> conflict on parallel changes to adjacent lines.
>
> * Bitkeeper generates a correct merge (again, because it's lucky).
>
> That's about 50/50 by straight numbers, but the first two are in much
> greater use than the rest, and I'm not sure if darcs's behavior is 100%
> intended.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mismerge case
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-08-10 at 21:36 +0100, Philip Martin wrote:
> How many of those merge tools are built on top of GNU diff?
From what I can tell:
* diff3 is part of diff, so obviously generates a conflict.
* CVS merging is built on top of gnu diff, so obviously generates a
conflict.
* "merge" is part of RCS, so might be independent from gnu dif, and
generates a conflict.
* pcdv merge (Codeville's new merge algorithm) generates a conflict
because it requires one line of context.
* darcs generates a correct merge (because it's lucky). This was a
bit of a surprise to zooko, who thought that darcs would generate a
conflict on parallel changes to adjacent lines.
* Bitkeeper generates a correct merge (again, because it's lucky).
That's about 50/50 by straight numbers, but the first two are in much
greater use than the rest, and I'm not sure if darcs's behavior is 100%
intended.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mismerge case
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2005-08-10 at 21:05 +0100, Philip Martin wrote:
>> We could make Subversion's diff require context, like GNU diff3, but
>> at the expense of making some currently successful merges into
>> conflicts. Would that be an improvement? It's not clear; in lots of
>> cases Subversion's ability to merge without context produces the right
>> result in cases where GNU diff would produce a conflict.
>
> I claim that most three-way merge tools do require some context, and we
> are being abnormally aggressive in producing successful merges with no
> context.
How many of those merge tools are built on top of GNU diff?
I have no objections to somebody making merge context optional, but I
like the current behaviour.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mismerge case
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-08-10 at 21:05 +0100, Philip Martin wrote:
> We could make Subversion's diff require context, like GNU diff3, but
> at the expense of making some currently successful merges into
> conflicts. Would that be an improvement? It's not clear; in lots of
> cases Subversion's ability to merge without context produces the right
> result in cases where GNU diff would produce a conflict.
I claim that most three-way merge tools do require some context, and we
are being abnormally aggressive in producing successful merges with no
context.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mismerge case
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> while gnu diff happens to produce a more natural diff. However, I
> think it's also the case that diff3 requires some unmodified context
> between changed lines in order to perform a clean merge, and we are
> not requiring any context, which is kind of unsafe.
We don't require context, see the merge_adjacent_changes test in
tests/libsvn_diff/diff-diff3-test.c.
> Can anyone more knowledgeable about libsvn_diff speak to that?
The change from
a
b
c
d
e
to
a
Q
c
d
e
i.e. the second line changes from b to Q, is to be merged into
V
b
W
X
Y
Z
b
c
d
e
Which of the two lines b should get changed to Q, the first, the
second or neither? Subversion doesn't rely on context, in this case
it gives:
$ tools/diff/diff3 mine orig your
V
Q
W
X
Y
Z
b
c
d
e
GNU diff3 requires context and so creates a conflict:
<<<<<<< mine
V
b
W
X
Y
Z
b
||||||| orig
a
b
=======
a
Q
>>>>>>> your
c
d
e
We could make Subversion's diff require context, like GNU diff3, but
at the expense of making some currently successful merges into
conflicts. Would that be an improvement? It's not clear; in lots of
cases Subversion's ability to merge without context produces the right
result in cases where GNU diff would produce a conflict.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org