On Saturday 27 January 2007 20:47, Kevin Grover wrote:
> > > >Jeff Smith schrieb:
> > > >>Agrivatingly, it stops the 'add' of 1000 files
> > > >>just because it hits one .c with inconsistent
> > > >>EOL styles (mixed "/n", "/r/n"). Heck, all I
> > > >>want to do is tell the stupid thing to ignore
> > > >>that, but there's no way except I manually find
> > > >>and edit the 10 out of the 1000 before adding!
> > > >>It's making it impossible to handle vendor releases of FreeRTOS.
>
> The file possibly being a JPEG (or any other binary format) is
> irrelevant. Subversion has determined that the file is text BEFORE
> scanning for EOL style, so you'll never hit that problem with binary
> files.
>
> However, I think there is a way around the problem. Turn on auto-props
> for source code extension (*.c, *.h, makefile, Makefile, etc....) and set
> svn:eol-style to 'native' (or whatever you want it to be).
It can still happen, if the tools on one platform do not behave identically.
This may be a tool ported from another platform or a multi-platform tool
being configured the wrong way. This stuff happens to me all the time when
I work under windoze using Unix tools.
I personally would prefer SVN to ask the user what to do, like:
File mystrangefile.txt is a text file, but has inconsistent line endings.
(1) Mark as binary file.
(2) Convert to local EOL style.
(3) Convert to local EOL (unix) and mark as eol-style-unix
(4) Convert to local EOL (unix) and mark as eol-style-native
(5) Abort.
Your choice: _
(maybe except if in batch mode in which it should do the safe thing: abort
with an error)
I myself think that whenever an eol-style is already configured, SVN should
just warn, convert, and go on without stopping.
Konrad
- application/pgp-signature attachment: stored
Received on Sun Jan 28 10:52:16 2007