Re: Local modification on checkout?

On Fri, Jan 18, 2013 at 5:27 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
>> Sent: vrijdag 18 januari 2013 11:50
>> To: Ryan Schmidt
>> Cc: Laird Nelson; users_at_subversion.apache.org
>> Subject: Re: Local modification on checkout?
>>
>
>
>> 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.
>
> Thanks for bringing this up..
>
> I expected a problem like this, but was never able to confirm this.
> (if you have a pointer to more details, please let me know)

Yeah, it's a nasty bug, and I had to dig deep to find the ultimate
cause :-). Most details are in the SVNKit issue [1].

I started suspecting this because of exactly this LF-normalization
issue, and the fact that some of my users saw this as "M" and others
didn't. It turned out to be correlated to a feature in IntelliJ IDEA
(which normally uses SVNKit under the hood) where you can optionally
select a native client for 'update' and 'status' to make these
operations faster. Users that had the mix of SVNKit + native saw the
unexpected M.

Apart from that, I also noticed that some user's working copies were
unusually slow when 'svn stat'ed on the command line, with lots of
hard disk activity, which was a bit unexpected for svn 1.7.

It's around that time I started asking on the users-list [2] for
scripts / tools that can report on timing mismatches, and there was
some discussion on letting 'svn status' optionally report or even fix
such mismatches (fixing on the fly turned out to be a bit hard,
because 'status' would have to take a write lock to do that, but there
was an issue filed to do that optionally [3] -- but the reporting of
those mismatches would also still be very valuable I think).

In the end I used this crude patch to diagnose timestamp-problems
quickly when running status:

[[[
Index: subversion/libsvn_wc/questions.c
===================================================================
--- subversion/libsvn_wc/questions.c (revision 1396561)
+++ subversion/libsvn_wc/questions.c (working copy)
@@ -363,6 +363,9 @@ svn_wc__internal_file_modified_p(svn_boolean_t *mo
                                                   dirent->filesize,
                                                   dirent->mtime,
                                                   scratch_pool));
+ else
+ fprintf(stdout, "Broken TS: %s (disk: %" APR_TIME_T_FMT " -
db: %" APR_TIME_T_FMT ")\n",
+ local_abspath, dirent->mtime, recorded_mod_time);
     }

   return SVN_NO_ERROR;
]]]

> This would exactly explain this problem.
> (Just like it explained a similar problem in our testsuite yesterday. Python
> appears to have a similar problem in its file timestamps)

Hm, it surprises me that Python has the same problem, but then again,
I don't know Python enough to know.

As mentioned in the issue, with SVNKit the problem is closely related
to Java, because the standard (platform-independent)
java.io.File#lastModified() reports milliseconds. Only as of Java 7
there is (finally) another API to get low-level file attributes, but
the SVNKit people still have to implement the stuff to make use of it
to fix their timestamp handling.

Perhaps Python has a similar (platform-independent)
millisecond-precision API that's used here?

[1] http://issues.tmatesoft.com/issue/SVNKIT-315

[2] http://thread.gmane.org/gmane.comp.version-control.subversion.user/109891

[3] http://subversion.tigris.org/issues/show_bug.cgi?id=4162

-- 
Johan