On 15.11.2020 19:16, Nathan Hartman wrote:
On Sat, Nov 14, 2020 at 4:51 AM Branko Čibej <br...@apache.org> wrote:
On 13.11.2020 17:37, Nathan Hartman wrote:
Done in r1883388. Added to the backport proposal but I'll let you un-veto it :-)
This fixes the issue on trunk, but when I merge the two revisions to
1.14.x ...
$ svn diff
svn: E135000: File '.../build/ac-macros/macosx.m4' has inconsistent newlines
svn: E135000: Inconsistent line ending style
$ svn ps svn:eol-style native build/ac-macros/macosx.m4
svn: E200009: File '.../build/ac-macros/macosx.m4' has inconsistent newlines
svn: E135000: Inconsistent line ending style
Did we really mean this? that 'svn diff' errors out on inconsistent
newlines? Really really? And that you can't make them consistent by
setting the svn:eol-style property (which 'svn merge' already did')?
Looks like a bug to me. I'll try to track it down... It has something
to do with eol-style processing. I also get "E200042: Additional
errors:" but there are no additional errors listed. Same result
happens regardless of the order of merging the two revisions, but
removing the svn-eol-style property makes 'svn diff' work normally.
Looks like this behaviour has been in the code for a long time. It's
correct that 'svn diff' doesn't try to "repair" the line endings, those
must show up in the diff, but failing is kind of wrong. It's correct for
'svn commit' iff we have svn:eol-style set, but IMO wrong for 'svn diff'.
Also I *do not* understand how that could even be an issue in this case,
since the line endings were fixed in the repository. Does 'svn merge' do
something wrong?
-- Brane
