On Wed, Feb 23, 2011 at 05:56:13AM -0500, John Szakmeister wrote: > On Wed, Feb 23, 2011 at 5:47 AM, Stefan Sperling <[email protected]> wrote: > > On Wed, Feb 23, 2011 at 04:56:03AM -0500, John Szakmeister wrote: > >> On Tue, Feb 22, 2011 at 1:35 PM, Stefan Sperling <[email protected]> wrote: > >> > When trying to 'svn import' files that have a mixed eol style, > >> > and at the same time using autoprops to set an svn:eol-style property > >> > with value 'native' on this file, svn import aborts with an "Inconsistent > >> > line ending style" error. Is there any specific reason for this? > >> > Can't we just normalize the file to LF (i.e. the repository normal form)? > >> > >> I think it was probably part of Subversion's "do no harm" decision > >> policy. If the type of the file was actually binary, and the > >> autoprops changed it, then the file would be corrupted from the > >> beginning. > > > > If that's the reasoning then why is it normalising the data > > for svn:eol-style with values other than 'native'? > > It's not so much the value that's the problem, it's the content. If > you normalize something that had inconsistent line endings, then you > can never get the original back. If it at least has consistent line > endings, then you do at least have the ability to fix the situation.
Hmmm, I'm not following. Maybe there's a misunderstanding. The code does already override any inconsistent line endings for svn:eol-style values CR, CRLF, and LF. It just doesn't do so for 'native'. So my question isn't about whether normalization should be done in the first place. It's about why it's only being done for the fixed values, and not for 'native' (which does translate to a fixed value in the repository). The feature isn't enabled by default anyway, so this isn't a question of modifying imported data by default. Users have to enable this in the config file before it has any effect.
