On Mon, Jan 25, 2021 at 6:37 PM Johan Corveleyn <jcor...@gmail.com> wrote:
> 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 This stems from the same issue Brane ran into while reviewing the item that is currently veto-blocked in 1.14.x STATUS: r1881534, r1883388, "unblock cross compiling." It is veto blocked because the patch we received contained CRLF line endings. When I applied and committed it, the CRLF line endings got into the repository. When Brane found the CRLF endings, I investigated and found that a bunch of m4 files did not have svn:eol-style properties (nor was *.m4 in svn:auto-props). I fixed that, but the fix is causing two issues: (1) 'svn diff' complains it can't work due to mixed line endings, and (2) the issue you just encountered. It affects Unix too. I think it's the property being introduced, not the actual line endings, that is causing this. Nathan
