> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: donderdag 6 juni 2013 03:02
> To: Philip Martin
> Cc: Subversion Development; Tobias Bading; Bert Huijben
> Subject: Re: Strange failure of log_tests.py#7 -- missing commit in
> guarantee_repos_and_wc ?
>
> 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?
I made some fixes to the test runner to clean up more left overs from
running the BDB tests.
The result without this fixes is that some tests start failing and failed
tests always leave their work area... So everything after a few failures
fails as well.
Bert
Received on 2013-06-06 10:35:53 CEST