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