[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1881534 - /subversion/trunk/build/ac-macros/macosx.m4

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 16 Nov 2020 17:31:29 +0000

Branko Čibej wrote on Mon, 16 Nov 2020 16:15 +0100:
> 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?

The file ends up with svn:eol-style=native set (even before the
propset) but a mix of LF and CRLF on disk. Passing it through
dos2unix(1) makes the error go away. Seems like several different bugs:

- Merging the propset left the file with inconsistent newlines.

- «svn diff» treated the inconsistency as a fatal error, even under
  -x--ignore-eol-style. It could have printed a diff (plus or minus
  a warning, when -x--ignore-eol-style isn't in effect).

- brane's idempotent «propset» failed.


Received on 2020-11-16 18:31:41 CET

This is an archived mail posted to the Subversion Dev mailing list.