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.
