Re: Local modification on checkout?

On Thu, Jan 17, 2013 at 11:45 PM, Ryan Schmidt
<subversion-2012c_at_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