You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Flemming Frandsen <dr...@gmail.com> on 2011/10/28 11:55:06 UTC
merge disagrees with diff
We're having a major problem with subversion, it seems that for some
changesets svn merge will do a different change than svn diff would
suggest.
Here's an example of that the problem looks like:
svn diff -c 648291 svn+ssh://myserver/somepath/stepws.xsd
Index: stepws.xsd
===================================================================
--- stepws.xsd (revision 648290)
+++ stepws.xsd (revision 648291)
@@ -366,6 +366,37 @@
</complexType>
<element name="getLOVValueIDsResponse"
type="tns:getLOVValueIDsResponseType"/>
+ <!-- getAssetSystemValues -->
+
+ <complexType name="getAssetSystemValuesRequestType">
+ <sequence>
+ <element name="accessContext" type="types:accessContext">
+ <annotation>
+ <documentation>username and password for the user
to access STEP as, and the URLs of the context and
+ workspace to access data through.
+ </documentation>
+ </annotation>
+ </element>
+ <element name="nodeURL" type="string">
+ <annotation>
+ <documentation>URL of the asset to obtain system
values from</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="getAssetSystemValuesRequest"
type="tns:getAssetSystemValuesRequestType"/>
+
+ <complexType name="getAssetSystemValuesResponseType">
+ <sequence>
+ <element name="values" type="types:value" minOccurs="0"
maxOccurs="unbounded">
+ <annotation>
+ <documentation>The attribute values</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="getAssetSystemValuesResponse"
type="tns:getAssetSystemValuesResponseType"/>
+
Now I tried to check out an older branch to backport that change:
> svn co svn+ssh://myserver/someotherpath
> cd someotherpath
> svn merge -c 648291 svn+ssh://myserver/somepath/stepws.xsd stepws.xsd
Conflict discovered in 'stepws.xsd'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
--- Merging r648291 into 'stepws.xsd':
C stepws.xsd
Summary of conflicts:
Text conflicts:
> svn diff
Index: stepws.xsd
===================================================================
--- stepws.xsd (revision 610503)
+++ stepws.xsd (working copy)
@@ -366,6 +366,76 @@
</complexType>
<element name="getLOVValueIDsResponse"
type="tns:getLOVValueIDsResponseType"/>
+<<<<<<< .working
+=======
+ <!-- getAssetSystemValues -->
+
+ <complexType name="getAssetSystemValuesRequestType">
+ <sequence>
+ <element name="accessContext" type="types:accessContext">
+ <annotation>
+ <documentation>username and password for the user
to access STEP as, and the URLs of the context and
+ workspace to access data through.
+ </documentation>
+ </annotation>
+ </element>
+ <element name="nodeURL" type="string">
+ <annotation>
+ <documentation>URL of the asset to obtain system
values from</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="getAssetSystemValuesRequest"
type="tns:getAssetSystemValuesRequestType"/>
+
+ <complexType name="getAssetSystemValuesResponseType">
+ <sequence>
+ <element name="values" type="types:value" minOccurs="0"
maxOccurs="unbounded">
+ <annotation>
+ <documentation>The attribute values</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="getAssetSystemValuesResponse"
type="tns:getAssetSystemValuesResponseType"/>
+
+ <!-- addLOVValueIDs -->
+
+ <complexType name="addLOVValueIDsRequestType">
+ <sequence>
+ <element name="accessContext" type="types:accessContext">
+ <annotation>
+ <documentation>username and password for the user
to access STEP as, and the URLs of the context and
+ workspace to access data through.
+ </documentation>
+ </annotation>
+ </element>
+ <element name="nodeURL" type="string">
+ <annotation>
+ <documentation>URL of the LOV to obtain values
from</documentation>
+ </annotation>
+ </element>
+ <element name="add" type="types:lovvalueid" minOccurs="1"
maxOccurs="unbounded">
+ <annotation>
+ <documentation>The list of LOV values to
add</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="addLOVValueIDsRequest"
type="tns:addLOVValueIDsRequestType"/>
+
+ <complexType name="addLOVValueIDsResponseType">
+ <sequence>
+ <element name="values" type="types:lovvalueid"
minOccurs="0" maxOccurs="unbounded">
+ <annotation>
+ <documentation>The new list of LOV values</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="addLOVValueIDsResponse"
type="tns:addLOVValueIDsResponseType"/>
+
+>>>>>>> .merge-right.r648291
<!-- getValuesByAttributeIds -->
<complexType name="getValuesByAttributeIdsRequestType">
As you can see the resulting change to the checked out file after
merge is different from the change reported by diff.
I've found this problem on 1.6.12 and reproduced it with a
home-compiled 1.7.1, the server runs ubuntu server 10.10.
Clients are mostly linux with mostly 1.6.12, but there are windows
machines and 1.7.1 clients as well.
I did not find any --dont-merge-random-crap option, so I'm very confused.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
Posted by Flemming Frandsen <dr...@gmail.com>.
On Fri, Oct 28, 2011 at 2:19 PM, Stefan Sperling <st...@elego.de> wrote:
> Does this explanation make sense?
Yes, very much, thank you for taking your time to look into this for
me, I'm sorry to have inconvenienced you, but hopefully someone with
the same problem will find the thread and be enlightened.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Oct 28, 2011 at 01:02:05PM +0200, Flemming Frandsen wrote:
> On Fri, Oct 28, 2011 at 12:58 PM, Andreas Krey <a....@gmx.de> wrote:
> > You didn't get a clean merge; you got a conflict. When you get a conflict,
> > it is your job to look at what you merged and at the proposed result,
> > and resolve it yourself.
>
> Yes, I have seen conflicts before, that's not what the problem is, I
> know how to handle conflicts.
>
> > (Can't tell without the three versions that have been requested.)
>
> Those versions were sent to the developer who requested them, I'd
> rather not have them on the public mailing list.
>
> The problem is that there are many more changes in the conflicted
> block than the diff suggested, iow: svn merge tried to add more lines
> than svn diff said it would.
I've taken a look at the files.
My brief analysis suggests that you are simply running into a case
where the diff3 algorithm doesn't work very well.
If you manually diff the files, you'll see that the extra block
of text which ended up in the merge target is the exact difference
between the merge-target and the merge-left version of the file.
I.e. try this (using the names of the files you sent me):
diff -u stepws-5.2.1-610503.xsd stepws-5.2.2-648290.xsd
diff -u stepws-5.2.2-648290.xsd stepws-5.2.2-648291.xsd
The first diff shows the "spurious" block being added ("bad block").
The second diff shows the block you want being added ("good block").
So why does Subversion end up showing both blocks?
The answer is that it has no way of matching the good block to
any postition in the merge-target, because it doesn't match anywhere.
Internally, the 3-way diff produced from the input files looks like this
(the decimal numbers below are line numbers, so you can easily verify
where the diff3 algorithm is pin-pointing region boundaries in the files):
(gdb) p *diff
$12 = {next = 0x20a346658, type = svn_diff__type_conflict,
original_start = 368, original_length = 36,
modified_start = 368, modified_length = 0,
latest_start = 368, latest_length = 67,
resolved_diff = 0x20a346610}
'original' is stepws-5.2.2-648290.xsd ("merge-left")
'modified' is stepws-5.2.1-610503) ("merge-target")
'latest' is stepws-5.2.2-648291.xsd ("merge-right")
As you can see, the diff3 algorithm found no section where the diff
between 'original' and 'latest' could be applied to 'modified'
(modified_length is zero).
This is because 'original' is assumed to be the last common version.
diff3 compares 'original' to 'modified' and 'original' to 'latest':
diff 'original'->'modified'
diff 'original'->'latest'
(see www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf)
Because you are cherry-picking to an old branch, th historical correspondance
between 'original' and 'modified' conflicts with the assumptions diff3 is
makeing. In fact, 'modified' equals 'original' if you remove the "bad block"
from 'original'. Your 'original' is really a newer version of the file
than 'modified' is.
So there is conflict, and what Subversion does in this case produces the
result you see. What it shows you is a diff2 between the 'modified' version
and the 'latest' version. This is deliberate, see this comment in
subversion/libsvn_diff/diff3.c:
/* ### If we have a conflict we can try to find the
* ### common parts in it by getting an lcs between
* ### modified (start to start + length) and
* ### latest (start to start + length).
* ### We use this lcs to create a simple diff. Only
* ### where there is a diff between the two, we have
* ### a conflict.
Obviously, this diff will not show what you tried to merge.
You were expecting to see the diff between 'original' and 'latest',
but Subversion shows the diff between 'modified' and 'latest'.
I would say this is working as designed.
You might argue that what Subversion is displaying in your case is
confusing, but off-hand I wouldn't know if there is a better way to
deal with this situation.
Even standard UNIX diff tools like diff3(1) and merge(1) (uses diff3)
produce the same result.
E.g. try this command, which outputs the same "bad block" as
Subversion does:
diff3 stepws-5.2.2-648290.xsd stepws-5.2.1-610503.xsd stepws-5.2.2-648291.xsd
With merge(1) I get the same result as Subversion produces, too:
merge -p -E stepws-5.2.2-648290.xsd stepws-5.2.1-610503.xsd
stepws-5.2.2-648291.xsd > stepws.merged
diff -u stepws-5.2.1-610503.xsd stepws.merged
Using the files you provided, I've verified that if you first cherry-pick
the change which adds the "bad block", and then cherry-pick the change
which adds the "good-block", there is no conflict.
Does this explanation make sense?
Re: merge disagrees with diff
Posted by Flemming Frandsen <dr...@gmail.com>.
On Fri, Oct 28, 2011 at 2:00 PM, Andreas Krey <a....@gmx.de> wrote:
> That only looks like that because of the way merging is described in the
> book.
Aaah! RTFM, is it?
> In essence, svn sees only two different (and conflicting) changes to
> a block of lines, and leaves it to you to deal with that. (Likewise
> do git and CVS.)
>
> This looks pretty much like your situation.
My god man! you're right!
I've managed to write a very minimal test case which demonstrates the problem:
#!/usr/bin/perl
use strict;
use warnings;
use FindBin qw($Bin);
system("svnadmin create repo") and die;
system("svn", 'co', "file://$Bin/repo", "checkout") and die;
open A, ">checkout/a" or die "Failed to create a: $!";
for my $i (1..10) {
print A "$i\n";
}
close A;
open B, ">checkout/b" or die "Failed to create b: $!";
for my $i (1..10) {
print B "$i\n";
print B "$i and a half\n" if $i == 5;
}
close B;
system("svn", "add", "checkout/a", "checkout/b") and die;
system("svn", "ci", "checkout", "-m", "Added some files to test on") and die;
open B, ">checkout/b" or die "Failed to create b: $!";
for my $i (1..10) {
print B "$i\n";
print B "$i and a quarter\n" if $i == 5;
print B "$i and a half\n" if $i == 5;
}
close B;
system("svn", "ci", "checkout", "-m", "Added an extra line") and die;
system("svn", "diff", "-c", '2', "file://$Bin/repo") and die;
system("svn", "merge", '--non-interactive', "-c", '2',
"file://$Bin/repo/b", "checkout/a") and die;
The change to b that I merge is:
Index: b
===================================================================
--- b (revision 1)
+++ b (revision 2)
@@ -3,6 +3,7 @@
3
4
5
+5 and a quarter
5 and a half
6
7
The conflict in a ends up being:
1
2
3
4
5
<<<<<<< .working
=======
5 and a quarter
5 and a half
>>>>>>> .merge-right.r2
6
7
8
9
10
I'm comforted that this only happens when there is a conflict, but
it's still terribly confusing for people and I wonder if trying to
apply the diff (as reported by svn diff) would lead to a less
confusing conflict as you would only have to deal with the actual
change you wanted to merge rather than the entire
Thank you all for your time.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 28 Oct 2011 13:02:05 +0000, Flemming Frandsen wrote:
...
> The problem is that there are many more changes in the conflicted
> block than the diff suggested, iow: svn merge tried to add more lines
> than svn diff said it would.
That only looks like that because of the way merging is described in the
book. It is true that if you merge the change from A to B into C and
get D, then diff(A,B) should be the same as diff(C,D). But this holds
only when there are no conflicts.
Example. A is:
one
two
three
four
five
six
seven
Add a line to get B:
one
two
three
three two thirds
four
five
six
seven
Meanwhile for C we have removed a few lines:
one
two
three
six
seven
And now we merge the diff(A,B) onto C and get:
one
two
three
<<<<<<< HEAD
=======
three two thirds
four
five
>>>>>>> work
six
seven
which means it looks like the merge is bringing in 'too much', but what
it is actually showing is that between the lines 'three' and 'seven'
that were in the baseline version of the file (A) there are no lines
left in C and three lines, partially 'new', in B.
In essence, svn sees only two different (and conflicting) changes to
a block of lines, and leaves it to you to deal with that. (Likewise
do git and CVS.)
This looks pretty much like your situation.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: merge disagrees with diff
Posted by Flemming Frandsen <dr...@gmail.com>.
On Fri, Oct 28, 2011 at 12:58 PM, Andreas Krey <a....@gmx.de> wrote:
> You didn't get a clean merge; you got a conflict. When you get a conflict,
> it is your job to look at what you merged and at the proposed result,
> and resolve it yourself.
Yes, I have seen conflicts before, that's not what the problem is, I
know how to handle conflicts.
> (Can't tell without the three versions that have been requested.)
Those versions were sent to the developer who requested them, I'd
rather not have them on the public mailing list.
The problem is that there are many more changes in the conflicted
block than the diff suggested, iow: svn merge tried to add more lines
than svn diff said it would.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 28 Oct 2011 12:49:35 +0000, Flemming Frandsen wrote:
...
> This is not the only time I've seen the problem manifest, but the
> circumstances where similar, in the other case another developer was
> trying to merge a change from version-1 to version-2, he too got extra
> changes in his merge target.
You didn't get a clean merge; you got a conflict. When you get a conflict,
it is your job to look at what you merged and at the proposed result,
and resolve it yourself.
Here it may simply be that you get the conflict because you want to merge
in the addition of a block of code but in the merge target surrounding
(here: following) blocks have been removed. Now you get all of those
within the conflict marker. (Can't tell without the three versions
that have been requested.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: merge disagrees with diff
Posted by Flemming Frandsen <dr...@gmail.com>.
On Fri, Oct 28, 2011 at 12:31 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> Here is something I don't understand. You just did a new checkout to
> someotherpath. The HEAD of your repository is at least 648291. How
> come that someotherpath/stepws.xsd is at revision 610503? That doesn't
> make sense.
I'm sorry, I cheated a tiny bit, the merge target was made using "svn
co -r 610503" to get the exact version where we first saw the problem,
that was needed because changes have been made in that branch since we
first saw the problem.
I can assure you the problem is exactly the same as originally
(without -r) and shows up with a clean checkout.
To make it less obscure, you can replace "somepath" with
"/branch/version-2" and "someotherpath" with "/branch/version-1".
In other words, what I'm trying to do is to backport a change from
version-2 to version-1, both version-1 and version-2 were forked off
from trunk.
The extra change in the target file appears the change just before the
wanted change in the source file (iow: it appears that the svn merge
command did what I would have expected if I had used svn merge -c
625829,648291 ... in stead of svn merge -c 648291 ...):
svn diff -c 625829 svn+ssh://myserver/somepath/stepws.xsd
Index: stepws.xsd
===================================================================
--- stepws.xsd (revision 625828)
+++ stepws.xsd (revision 625829)
@@ -366,6 +366,42 @@
</complexType>
<element name="getLOVValueIDsResponse"
type="tns:getLOVValueIDsResponseType"/>
+ <!-- addLOVValueIDs -->
+
+ <complexType name="addLOVValueIDsRequestType">
+ <sequence>
+ <element name="accessContext" type="types:accessContext">
+ <annotation>
+ <documentation>username and password for the user
to access STEP as, and the URLs of the context and
+ workspace to access data through.
+ </documentation>
+ </annotation>
+ </element>
+ <element name="nodeURL" type="string">
+ <annotation>
+ <documentation>URL of the LOV to obtain values
from</documentation>
+ </annotation>
+ </element>
+ <element name="add" type="types:lovvalueid" minOccurs="1"
maxOccurs="unbounded">
+ <annotation>
+ <documentation>The list of LOV values to
add</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="addLOVValueIDsRequest"
type="tns:addLOVValueIDsRequestType"/>
+
+ <complexType name="addLOVValueIDsResponseType">
+ <sequence>
+ <element name="values" type="types:lovvalueid"
minOccurs="0" maxOccurs="unbounded">
+ <annotation>
+ <documentation>The new list of LOV values</documentation>
+ </annotation>
+ </element>
+ </sequence>
+ </complexType>
+ <element name="addLOVValueIDsResponse"
type="tns:addLOVValueIDsResponseType"/>
+
<!-- getValuesByAttributeIds -->
<complexType name="getValuesByAttributeIdsRequestType">
> Are you sure that the merge target (someotherpath) was a clean
> checkout, with nothing locally modified?
Absolutely.
> The only explanation (short of a bug in 'merge') I can come up with
> for this behavior, is if someotherpath/stepws.xsd was already modified
> in the working copy (already containing those extra added lines that
> suddenly seemed to appear here).
It did not, it's a completely clean checkout, done from scratch.
This is not the only time I've seen the problem manifest, but the
circumstances where similar, in the other case another developer was
trying to merge a change from version-1 to version-2, he too got extra
changes in his merge target.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Oct 28, 2011 at 11:55 AM, Flemming Frandsen <dr...@gmail.com> wrote:
> We're having a major problem with subversion, it seems that for some
> changesets svn merge will do a different change than svn diff would
> suggest.
>
> Here's an example of that the problem looks like:
>
>
> svn diff -c 648291 svn+ssh://myserver/somepath/stepws.xsd
>
> Index: stepws.xsd
> ===================================================================
> --- stepws.xsd (revision 648290)
> +++ stepws.xsd (revision 648291)
> @@ -366,6 +366,37 @@
> </complexType>
> <element name="getLOVValueIDsResponse"
> type="tns:getLOVValueIDsResponseType"/>
>
> + <!-- getAssetSystemValues -->
> +
> + <complexType name="getAssetSystemValuesRequestType">
> + <sequence>
> + <element name="accessContext" type="types:accessContext">
> + <annotation>
> + <documentation>username and password for the user
> to access STEP as, and the URLs of the context and
> + workspace to access data through.
> + </documentation>
> + </annotation>
> + </element>
> + <element name="nodeURL" type="string">
> + <annotation>
> + <documentation>URL of the asset to obtain system
> values from</documentation>
> + </annotation>
> + </element>
> + </sequence>
> + </complexType>
> + <element name="getAssetSystemValuesRequest"
> type="tns:getAssetSystemValuesRequestType"/>
> +
> + <complexType name="getAssetSystemValuesResponseType">
> + <sequence>
> + <element name="values" type="types:value" minOccurs="0"
> maxOccurs="unbounded">
> + <annotation>
> + <documentation>The attribute values</documentation>
> + </annotation>
> + </element>
> + </sequence>
> + </complexType>
> + <element name="getAssetSystemValuesResponse"
> type="tns:getAssetSystemValuesResponseType"/>
> +
>
>
>
> Now I tried to check out an older branch to backport that change:
>> svn co svn+ssh://myserver/someotherpath
>> cd someotherpath
>> svn merge -c 648291 svn+ssh://myserver/somepath/stepws.xsd stepws.xsd
> Conflict discovered in 'stepws.xsd'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: p
> --- Merging r648291 into 'stepws.xsd':
> C stepws.xsd
> Summary of conflicts:
> Text conflicts:
>
>
>> svn diff
>
>
> Index: stepws.xsd
> ===================================================================
> --- stepws.xsd (revision 610503)
Here is something I don't understand. You just did a new checkout to
someotherpath. The HEAD of your repository is at least 648291. How
come that someotherpath/stepws.xsd is at revision 610503? That doesn't
make sense.
Are you sure that the merge target (someotherpath) was a clean
checkout, with nothing locally modified?
The only explanation (short of a bug in 'merge') I can come up with
for this behavior, is if someotherpath/stepws.xsd was already modified
in the working copy (already containing those extra added lines that
suddenly seemed to appear here).
--
Johan
> +++ stepws.xsd (working copy)
> @@ -366,6 +366,76 @@
> </complexType>
> <element name="getLOVValueIDsResponse"
> type="tns:getLOVValueIDsResponseType"/>
>
> +<<<<<<< .working
> +=======
> + <!-- getAssetSystemValues -->
> +
> + <complexType name="getAssetSystemValuesRequestType">
> + <sequence>
> + <element name="accessContext" type="types:accessContext">
> + <annotation>
> + <documentation>username and password for the user
> to access STEP as, and the URLs of the context and
> + workspace to access data through.
> + </documentation>
> + </annotation>
> + </element>
> + <element name="nodeURL" type="string">
> + <annotation>
> + <documentation>URL of the asset to obtain system
> values from</documentation>
> + </annotation>
> + </element>
> + </sequence>
> + </complexType>
> + <element name="getAssetSystemValuesRequest"
> type="tns:getAssetSystemValuesRequestType"/>
> +
> + <complexType name="getAssetSystemValuesResponseType">
> + <sequence>
> + <element name="values" type="types:value" minOccurs="0"
> maxOccurs="unbounded">
> + <annotation>
> + <documentation>The attribute values</documentation>
> + </annotation>
> + </element>
> + </sequence>
> + </complexType>
> + <element name="getAssetSystemValuesResponse"
> type="tns:getAssetSystemValuesResponseType"/>
> +
> + <!-- addLOVValueIDs -->
> +
> + <complexType name="addLOVValueIDsRequestType">
> + <sequence>
> + <element name="accessContext" type="types:accessContext">
> + <annotation>
> + <documentation>username and password for the user
> to access STEP as, and the URLs of the context and
> + workspace to access data through.
> + </documentation>
> + </annotation>
> + </element>
> + <element name="nodeURL" type="string">
> + <annotation>
> + <documentation>URL of the LOV to obtain values
> from</documentation>
> + </annotation>
> + </element>
> + <element name="add" type="types:lovvalueid" minOccurs="1"
> maxOccurs="unbounded">
> + <annotation>
> + <documentation>The list of LOV values to
> add</documentation>
> + </annotation>
> + </element>
> + </sequence>
> + </complexType>
> + <element name="addLOVValueIDsRequest"
> type="tns:addLOVValueIDsRequestType"/>
> +
> + <complexType name="addLOVValueIDsResponseType">
> + <sequence>
> + <element name="values" type="types:lovvalueid"
> minOccurs="0" maxOccurs="unbounded">
> + <annotation>
> + <documentation>The new list of LOV values</documentation>
> + </annotation>
> + </element>
> + </sequence>
> + </complexType>
> + <element name="addLOVValueIDsResponse"
> type="tns:addLOVValueIDsResponseType"/>
> +
> +>>>>>>> .merge-right.r648291
> <!-- getValuesByAttributeIds -->
>
> <complexType name="getValuesByAttributeIdsRequestType">
>
>
> As you can see the resulting change to the checked out file after
> merge is different from the change reported by diff.
>
> I've found this problem on 1.6.12 and reproduced it with a
> home-compiled 1.7.1, the server runs ubuntu server 10.10.
>
> Clients are mostly linux with mostly 1.6.12, but there are windows
> machines and 1.7.1 clients as well.
>
> I did not find any --dont-merge-random-crap option, so I'm very confused.
>
> --
> Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
>
Re: merge disagrees with diff
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Oct 28, 2011 at 11:55:06AM +0200, Flemming Frandsen wrote:
> We're having a major problem with subversion, it seems that for some
> changesets svn merge will do a different change than svn diff would
> suggest.
This does indeed look like a bug in merge.
Is it possible for you to provide the following files?
>From merge source:
stepws.xsd@648290
stepws.xsd@648291
>From merge target:
stepws.xsd@610503
If necessary, you can email them in private and I promise to only
share them among Subversion developers for debugging purposes.
Re: merge disagrees with diff
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 28.10.2011 11:55, schrieb Flemming Frandsen:
> We're having a major problem with subversion, it seems that for some
> changesets svn merge will do a different change than svn diff would
> suggest.
It took me a while of scrolling up and down to find the difference, but
IIUC the problem is A) that there is a conflict and B) that the added
code contains the stuff following the "addLOVValueIDs" comment.
A few things I noticed:
- In trunk, the text was added to the end of the file, while in the
branch it seems to have been merged into the middle somewhere. Question
is where should it have been applied? You might be hitting some
limitations of the merge algorithm here, too.
- You mentioned that you have clients on different OS families. I know
that SVN is a bit picky when things like line endings differ between
source and target of a merge. I've repeatedly had whole files that were
reported as conflicting because of that. If the line endings are even
mixed within a file, different, unpleasant things could happen. In my
case it was caused by setting svn:eol-style in the trunk and then
merging to the branch without svn:eol-style.
- Another way to mess with lineendings is to check out on one system and
then use that working copy on another. Typically that happens when
putting the WCs on a shared directory or when using it with Cygwin and
MS Windows.
> I did not find any --dont-merge-random-crap option, so I'm very confused.
How confused would you be if you had found that option? ;D
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************