You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2011/02/11 18:04:09 UTC

libsvn_wc/merge.c:detranslate_wc_file EOL text conflicts

I've been looking at some spurious text conflicts during merge that are
caused because we attempt to merge files with different line endings.
The script at the end of this mail shows the problem, it's a very simple
merge and it doesn't change the EOL style.

The problem is detranslate_wc_file.  It gets the current EOL style for
the file and then "translates" the file from the current style to the
current style.  That makes no sense.  I think it should be translating
from current style to repos style.  The hack below fixes the conflict.

Index: subversion/libsvn_wc/merge.c
===================================================================
--- subversion/libsvn_wc/merge.c	(revision 1069761)
+++ subversion/libsvn_wc/merge.c	(working copy)
@@ -254,7 +254,7 @@
 
       SVN_ERR(svn_subst_copy_and_translate4(source_abspath,
                                             detranslated,
-                                            eol,
+                                            "\n",
                                             TRUE /* repair */,
                                             keywords,
                                             FALSE /* contract keywords */,


But does cause 3 FAILs in merge_tests.py:
FAIL:  merge_tests.py 34: conflict markers should match the file's eol style
FAIL:  merge_tests.py 35: handle eol-style propchange during merge
FAIL:  merge_tests.py 110: dav skelta mode can cause spurious conflicts

I'm stuggling to understand this.  I don't understand the documentation
for detranslate_wc_file.  Is it supposed to convert to repos EOL or
local EOL?  1.6 gets this merge wrong as well, has merge been broken for
so long?


#!/bin/sh -e
svn=svn
svnadmin=svnadmin
svnmucc=svnmucc
rm -rf repo wc
url=file://`pwd`/repo
svnadmin create repo
svn mkdir -mm --parents $url/A/B
svnmucc -mm -- put - $url/A/B/f << EOD
L1
L2
L3
EOD
svnmucc -mm propset svn:eol-style CRLF $url/A/B/f
svn cp -mm $url/A $url/X
svnmucc -mm -- put - $url/A/B/f << EOD
L1xxx
L2
L3
EOD
svnmucc -mm -- put - $url/X/B/f << EOD
L1
L2
L3xxx
EOD
svn co $url/A wc
svn merge ^/X wc

-- 
Philip

Re: libsvn_wc/merge.c:detranslate_wc_file EOL text conflicts

Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@e-reka.si> writes:

> On 11.02.2011 19:38, Philip Martin wrote:
>> Am I misunderstanding how the eol stuff works?  I thought the repository
>> always stored files with LF and the svn:eol-style determined how the
>> client converted the file.

> Line endings are only canonicalized to LF in the repository if
> svn:eol-style is "native". It's been this way since the property was
> first introduced way back when.

That would explain things.  It appears I have forgotten how this stuff
works :-(

-- 
Philip

Re: libsvn_wc/merge.c:detranslate_wc_file EOL text conflicts

Posted by Branko Čibej <br...@e-reka.si>.
On 11.02.2011 19:38, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Philip Martin <ph...@wandisco.com> writes:
>>
>>> But does cause 3 FAILs in merge_tests.py:
>>> FAIL:  merge_tests.py 34: conflict markers should match the file's eol style
>>> FAIL:  merge_tests.py 35: handle eol-style propchange during merge
>>> FAIL:  merge_tests.py 110: dav skelta mode can cause spurious conflicts
>> 110 was spurious, I had other changes in my tree.
> Am I misunderstanding how the eol stuff works?  I thought the repository
> always stored files with LF and the svn:eol-style determined how the
> client converted the file.
>
> At present merge_tests.py 34 is creating a file with CRLF endings,
> setting svn:eol-style to CRLF and committing it.  The repository file
> has CRLF endings.  I was expecting it to get converted to LF before
> being sent to the repository.

Line endings are only canonicalized to LF in the repository if
svn:eol-style is "native". It's been this way since the property was
first introduced way back when.

-- Brane

Re: libsvn_wc/merge.c:detranslate_wc_file EOL text conflicts

Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:

> Philip Martin <ph...@wandisco.com> writes:
>
>> But does cause 3 FAILs in merge_tests.py:
>> FAIL:  merge_tests.py 34: conflict markers should match the file's eol style
>> FAIL:  merge_tests.py 35: handle eol-style propchange during merge
>> FAIL:  merge_tests.py 110: dav skelta mode can cause spurious conflicts
>
> 110 was spurious, I had other changes in my tree.

Am I misunderstanding how the eol stuff works?  I thought the repository
always stored files with LF and the svn:eol-style determined how the
client converted the file.

At present merge_tests.py 34 is creating a file with CRLF endings,
setting svn:eol-style to CRLF and committing it.  The repository file
has CRLF endings.  I was expecting it to get converted to LF before
being sent to the repository.

-- 
Philip

Re: libsvn_wc/merge.c:detranslate_wc_file EOL text conflicts

Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:

> But does cause 3 FAILs in merge_tests.py:
> FAIL:  merge_tests.py 34: conflict markers should match the file's eol style
> FAIL:  merge_tests.py 35: handle eol-style propchange during merge
> FAIL:  merge_tests.py 110: dav skelta mode can cause spurious conflicts

110 was spurious, I had other changes in my tree.

-- 
Philip