On Wed, Jun 5, 2013 at 2:43 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
...
>> But even if the timestamp after the edit is precisely the same as
>> after the checkout, I don't understand how that can lead to 'commit'
>> not seeing that the file is modified: the edit changed the filesize,
>> and I thought both timestamp and filesize were considered to check for
>> modified files ...
>
> You are correct: both the timestamp and the filesize are checked (the
> code is in svn_wc__internal_file_modified_p). The timestamp "problem"
> only causes modifications to be missed if those modifications don't
> change the filesize. In this case the filesize should have changed.
OK, thanks. So certainly something fishy happened here. Some more
thoughts below.
On Wed, Jun 5, 2013 at 1:15 PM, Tobias Bading <tbading_at_web.de> wrote:
...
> I had a similar timestamp related problem with diff-test 60. (See thread
> http://mail-archives.apache.org/mod_mbox/subversion-users/201305.mbox/%3C519DDBE3.5040909%40web.de%3E
> on the users list for details, if you're interested.)
Thanks for jumping in here. Yes, I read that thread. But I don't think
it's the same problem (see below).
> TL;DR version of that thead:
> If a file's timestamp doesn't change, Subversion assumes that it is
> unmodified. Besides, Subversion's svn_io_sleep_for_timestamps()
> implementation is making assumptions that aren't valid in all cases. The
> cause of my test failures was a bad Linux kernel (reported here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1185730) combined with
> Subversion's assumption that taking a nap for one millisecond would be
> enough to get a fresh timestamp afterwards.
In this case, the filesize has also changed, so Subversion should
still see it, regardless of timestamp.
> The output you provided looks like you're using Windoze, so a bad Linux
> kernel is probably not your problem ;-). Do you have a very fast machine and
> use a SSD? What filesystem do you use? NTFS?
Yes, I'm using Windows, so it's definitely not a bad Linux kernel :-).
It's also likely not a problem with the OS or filesystem in general,
since I've not changed it in years, and have been using it already a
long time to test svn releases.
I'm actually running the tests on a Ramdisk (with an NTFS filesystem).
Also nothing new, been using it this way for years without any
problems.
However, I'm wondering now if perhaps there's an issue with the size
of the ramdisk (and increased need for disk space during the tests).
My ramdisk is only 128 MB large, which has sufficed until now. Perhaps
I now need to enlarge it. I'll try increasing it to 256 MB, and
rerunning the testsuite a couple of times.
@Bert: you made some commits recently related to disk usage of the
test-suite. Can you summarize a bit what kinds of failures you got,
and what changes you made for this? And are these in 1.8.0-rc2, or
will they be in rc3?
In one of your commit messages you specifically said that it should be
possible to run the test-suite in parallel on a 256 MB ramdisk. I
don't run the tests in parallel, but perhaps 128 MB has become too
small, even for non-parallellized test runs.
All that said: if these spurious failures turn out to be
diskspace-related, I'm still a bit worried: how come I didn't see a
big glaring error message in the test log? But first, let's try to
check this hypothesis by rerunning the tests on a larger ramdisk.
--
Johan
Received on 2013-06-06 03:02:32 CEST