[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Strange failure of log_tests.py#7 -- missing commit in guarantee_repos_and_wc ?

From: Tobias Bading <tbading_at_web.de>
Date: Thu, 06 Jun 2013 11:47:51 +0200

On 06.06.2013 10:38, Bert Huijben wrote:
> [...]
>
>> Grrrr. The author of diff-test 60 has a nice sense of humor it seems
>> ;-). The merge in that test changes a lot of lines, but the size of file
>> 3449_spurious stays the same. I didn't realize this until now. BTW, with
>> the bad kernel, I've once seen special-test 21 (update_symlink) fail as
>> well. Same reason I guess, a symbolic link is supposed to be changed
>> from "link A/mu" to "link iota", so the file's size doesn't change and
>> commit does nothing at all.
> Can you provide a patch to these two tests that still make the tests check
> their original target, but not trigger the timestamp problem?
>
> I can probably fix this diff test, but fully testing the symlink scenarios
> is not possible when running on Windows.

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. 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.

Tobias
Received on 2013-06-06 11:48:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.