On 6/14/07, Lübbe Onken <l.onken@rac.de> wrote:
> I wrote:
>
> > Hi Lasse,
> ...
> >> Upon reading in on this, it seems SVN will keep the files in an
> >> internal state with only the LF characters in place,
> >
> > ...if the svn:eol-style property is set. If the property is
> > not set, svn
> > neither reports inconsistencies nor touches the line endings.
Then the question again remains: what specifically won't work for me
if I don't specify this setting for my files? Visual Studio 2005 which
produces these files produces files with both different encodings and
different line endings styles depending on wether the file is
generated or not and resource script files are sometimes generated
with different line endings.
Basically, within each file, the line endings are consistent, but
looking at two different files of the same type might have different
line endings.
>
> Which in part contradicts my following observation with the current nightly
>
> > ...
> > When I do this with a current nightly, the commit fails and I get an
> > "inconsistent newlines" error message in the commit dialog.
> > This happens every time i try. I can't commit this file and the file
> > doesn't have the svn:eol-style property set.
And this probably works too, but it seems that the problem is that the
line endings check "bleeds over" from one file to another in some
cases so that a file that is ok internally gets compared to the wrong
setting and is reported as inconsistent through the Add command,
however just executing Add again adds the file without complaints. I
can reproduce the problem by using my directory of WOW addons (which
range in about 233mb and 9000 files from diffferent sources, mac and
windows), and I was able to add and commit all files eventually.
>
> IIRC it used to be as I said above, but my latest observation tells me
> somthing else.
I will try the latest builds using SVN 1.5.0 to see if the problem is there.
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
Received on Thu Jun 14 14:47:49 2007