On Wed, Feb 23, 2011 at 05:56:13AM -0500, John Szakmeister wrote:
> On Wed, Feb 23, 2011 at 5:47 AM, Stefan Sperling <stsp_at_elego.de> 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 <stsp_at_elego.de> 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.
Received on 2011-02-23 12:20:54 CET