On Thu, Jun 6, 2013 at 10:47 AM, Tobias Bading <tbading_at_web.de> wrote:
> One could try to insert lines like this (already present in diff_tests.py in
> one test)
>
> # sleep to guarantee timestamp change
> time.sleep(1.1)
>
> at the proper places. But what are the proper places? Potentially every
> merge or commit may 'fail' if the content of a file is changed, but
> timestamp and size aren't.
And to what end? Doing that just would hide timestamp sleep issues.
In the interest of test speed we turn sleep for timestamps off when
running tests and avoid changing files in ways that don't change the
file size already.
> I think coming up with a safer implementation of
> svn_io_sleep_for_timestamps would be a better long-term solution. The chance
> of encountering such a failure increases as CPUs become faster and faster,
> but the accuracy of file modification timestamps stays the same. Even on
> 'good' Linux kernels, this accuracy seems to be only 0.01 or 0.004 seconds.
> I almost feel the itch to rebuild Subversion 1.8 RC2 with SQLITE_NO_SYNC
> #define'd to see whether more tests fail due to faster operations without
> SQLite's fsync calls.
Clearly svn_io_sleep_for_timestamps() needs some more thought. There
was some discussions between Julian, Philip and myself about this a
while back. svn_io_sleep_for_timestamps() can actually make things
worse if we're using commit times as the timestamps.
As far as how good the timestamp accuracy is, I was under the
impression that ext4 had nanosecond timestamp resolution.
Received on 2013-06-06 13:04:50 CEST