> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com]
> Sent: donderdag 17 januari 2013 23:46
> To: Laird Nelson
> Cc: users@subversion.apache.org
> Subject: Re: Local modification on checkout?
>
>
> On Jan 17, 2013, at 15:30, Laird Nelson wrote:
>
> > Hello; we're seeing a local modification being reported on a particular
file
> on a clean checkout. We're using svn 1.7.7.
> >
> > The file in question has the svn:eol-style property set to native.
> >
> > What I mean by this:
> >
> > A fresh checkout happens (svn co ...).
> >
> > Down comes the whole project. So far so good.
> >
> > Then another part of our build infrastructure does an svn status.
> >
> > svn status reports that this file is locally modified (M). There are no
> intervening steps. That is, it's checkout, then svn status.
> >
> > Does automatic eol conversion show up as a local modification in svn
status
> output?
>
> No, it shouldn't.
>
> > I can't reproduce this on either a Windows or a Mac. It appears to be
only
> on this machine, which, I know, sounds mad.
>
> When a file has svn:eol-style set to native, the Subversion client is
supposed
> to normalize the file to LF line endings before sending it to the
repository to
> be committed. The Subversion server does not verify that this has been
> done, so it is possible for badly-written Subversion clients to commit
files
> with the wrong line endings. If a third-party svn client (git-svn?) was
used to
> commit this file, that might be a possible cause to investigate. Although
it's
> strange you only see the problem on one system.
>
> When checking out (or updating) a working copy, if any files have svn:eol-
> style set to native, then the Subversion client transforms the line
endings of
> those files from LF to whatever svn:eol-style says to do before placing
them
> in the working copy. This can lead to unexpected situations if you check
out a
> working copy on an OS with one line ending style and then look at it or
> update it from an OS with a different line ending style. If you think this
might
> have happened, check out a new working copy, and use it only on a single
> system.
>
> Or perhaps again if you checked out or updated using a third-party svn
client
> that did not transform line endings in response to svn:eol-style native,
then
> you might later have a problem.
A lot of users have SvnKit in their Jenkins installation. Are you sure that
you aren't mixing a normal svn with some svnkit version?
Bert
