On Thu, Jan 17, 2013 at 11:45 PM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > > 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. >
I'm 99% sure that the above (someone committed a file with svn:eol-style=native, but it wasn't correctly LF-normalized by the client) is the root cause of your problem. I've seen this happening with git-svn (on Windows), but I also suspect some older versions of SVNKit of a bug in this area (I have not seen it with later version of SVNKit (>=1.7)). See also issue #4065 [1] about the server not enforcing this. A way to verify this is to go looking for the corresponding pristine file (you can find the checksum of the file by running 'svn info $thefile', then go looking for the pristine file with the sha1 as filename in .svn/pristine). That file should normally have LF endings (for an svn:eol-style=native file). If it has CRLF, then you know its line-ending normalization was done incorrectly, so you can regard it as "corrupt". You can fix this by committing the "Modification" that is now flagged in your working copy (it will then be correctly normalized by your client). Now, why does this show up in one working copy, but not in others? That has to do with the optimization in 'svn status': if filesize and last-mod-time of the file on disk matches with the svn metadata, then it will be regarded as not-modified (without looking at the contents). If the last-mod-time differs, the file contents will be compared with the pristine, and in that case it shows up as modified. In other working copies, if you 'touch $thefile', then run 'svn status', it will probably also show up as modified. Further, when mixing SVNKit with native svn usage, it's possible that last-mod-times are already mismatching immediately after checkout. That's because of an issue in SVNKit [2], where it only notes the last-mod-time in the svn metadata up to millisecond precision. So if you 'svnkit co', followed by 'nativesvn status', all files will have mismatching timestamps, so they'll all be checksummed. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4065 - server should enforce LF normalization for svn:eol-style=native files [2] http://issues.tmatesoft.com/issue/SVNKIT-315 - SVNKit records lastModified times truncated to ms precision, even though filesystem has higher precision, leading to slower working copies because of mismatching timestamps -- Johan
