I'm seeing that checkout does not always sleep for long enough for
timestamp-based change detection to be reliable:
svnadmin create repo
svn -mm import repo/format file://`pwd`/repo/f
svn co file://`pwd`/repo wc
echo x > wc/f
svn st wc
For some checkouts status shows the modification of wc/f, for other
checkouts it does not.
The problem is that my filesystem has about 4ms timestamp resolution
while svn_io_sleep_for_timestamps() only sleeps for 1ms. I can
determine the resolution experimentally using:
echo x > f && stat f | grep Modify && echo y > f && stat f | grep Modify
often that prints the same timestamp twice, but when the timestamps
differ they typically differ by about 4ms:
Modify: 2014-03-24 16:40:17.566569826 +0000
Modify: 2014-03-24 16:40:17.570569785 +0000
In order to avoid missing changes I need to change
svn_io_sleep_for_timestamps:
Index: subversion/libsvn_subr/io.c
===================================================================
--- subversion/libsvn_subr/io.c (revision 1580884)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -1315,7 +1315,7 @@ svn_io_sleep_for_timestamps(const char *path, apr_
/* Sleep for at least 1 millisecond.
(t < 1000 will be round to 0 in apr) */
- apr_sleep(1000);
+ apr_sleep(4000);
return;
}
I'm running a standard 64-bit Debian/stable kernel with working copies
on an ext4 filesystem on a local SSD. I believe the 4ms is related to
the kernel's CONFIG_HZ=250 setting (it also has CONFIG_NO_HZ=y). Now I
could build a custom kernel and increase the resolution but I think
Subversion should support what is essentially a standard Linux setup. I
think we should increase the sleep to at least 10ms on the basis that
Linux kernels built with CONFIG_HZ=100 are not unusual. This does
penalise systems with true nanosecond resolution as they will sleep 9ms
more than necessary.
I've also got an ext3 filesystem on a spinning disk but that doesn't
show the problem because timestamps are always whole seconds and so
svn_io_sleep_for_timestamps uses a different code path.
--
Philip
