On 15.11.2020 19:16, Nathan Hartman wrote:
> On Sat, Nov 14, 2020 at 4:51 AM Branko Čibej <brane_at_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
Received on 2020-11-16 16:16:37 CET