While working on the javahl-1.14-fixes branch [1] I wanted to perform a catch-up merge with trunk, but ran into this:
(javahl-1.14-fixes being a clean, uniform-revision checkout of the branch) [[[ C:\svn\javahl-1.14-fixes>svn merge https://svn.apache.org/repos/asf/subversion/trunk --- Merging r1882126 through r1885907 into '.': ... CU build\ac-macros\compiler.m4 ... Summary of conflicts: Text conflicts: 1 Merge conflict discovered in file 'build\ac-macros\compiler.m4'. Select: (p) Postpone, (df) Show diff, (e) Edit file, (m) Merge, (s) Show all options: ]]] The branch itself was created from trunk in r1882126 [2]. Since then, the file compiler.m4 has seen two commits on trunk: * r1883390 [3]: *.m4 files were changed to svn:eol-style=native * r1883715 [4]: content change to compiler.m4 (among other things) If I split the merge range in two, the conflict disappears: [[[ C:\svn\javahl-1.14-fixes>svn merge -r1:1883714 https://svn.apache.org/repos/asf/subversion/trunk --- Merging r1882126 through r1883714 into '.': ... U build\ac-macros\compiler.m4 ... --- Recording mergeinfo for merge of r1882126 through r1883714 into '.': U . C:\research\svn\dev\javahl-1.14-fixes>svn merge https://svn.apache.org/repos/asf/subversion/trunk --- Merging r1883715 through r1885907 into '.': ... U build\ac-macros\compiler.m4 ... --- Recording mergeinfo for merge of r1882126 through r1885907 into '.': G . ]]] Sigh ... Probably y'all on *nix won't see this with the above example, because the svn:eol-style=native change didn't have an actual effect on the contents of the file in your working copy. Perhaps fabricating another example where, for example, you change svn:eol-style=LF to svn:eol-style=CRLF or something like that might reproduce it. This is obviously not good, but I suppose it's a long standing issue. I've quickly searched our issue tracker, and found one vaguely similar issue: SVN-3657 (dav update report handler in skelta mode can cause spurious conflicts), fixed in 1.7.0. But this had to do with a spurious prop-change being sent by the server, so was fixed on the server side. The symptoms on the client-side look similar though. I guess I should continue for now by splitting the merge range, and performing the catch-up merge that way. But I ran out of time for tonight, and still have barely looked at the actual content of the javahl-1.14-fixes branch ... hopefully I'll have better luck tomorrow. [1] https://lists.apache.org/thread.html/r287a52d298bc763a95c45de7183a27b48030493080d81552f5a2d673%40%3Cdev.subversion.apache.org%3E [2] https://svn.apache.org/r1882126 [3] https://svn.apache.org/r1883390 [4] https://svn.apache.org/r1883715 [5] https://issues.apache.org/jira/browse/SVN-3657 -- Johan
