Re: shelf-tests failure on macOS

Bert Huijben wrote on 2018-06-14:
> On the testsuite we explicitly disable the sleeps via the environment
> variable designed for this (except for a few specific tests). We
> compensate for this problem in quite a few places by making sure that we
> also change the number of characters in the file.

Thank you Bert! That was one of the remaining pieces of the puzzle. After adding 'sleep for timestamps' in the unshelve code in r1833532, I have again changed the tests to use files that are all different lengths in r1833565, so the tests can work with the sleep disabled.

Then I fixed one more timestamp-related issue in r1833577: we can't depend on timestamp-ordered output of 'svn shelves'.

- Julian

> > -----Original Message-----
> > From: Julian Foad [mailto:julianfoad_at_apache.org]
> > Sent: donderdag 14 juni 2018 19:35
> > To: Philip Martin <philip_at_codematters.co.uk>
> > Cc: dev_at_subversion.apache.org
> > Subject: Re: shelf-tests failure on macOS
> >
> > Philip Martin wrote on 2018-06-14:
> > > Philip Martin <philip_at_codematters.co.uk> writes:
> > > > Julian Foad <julianfoad_at_apache.org> writes:
> > > >> The most unusual thing about these failing tests is the data they
> > > >> write. Strings of 5 or 6 low-value bytes, like:
> > > >>
> > > >> '\0\1\2\3\4\5'
> > > >> '\5\4\3\2\1\0'
> > > >
> > > > Those are the same size. Could it be a filesystem timestamp resolution
> > > > issue? The file changes but the timestamp does not and some change is
> > > > not detected?
> > >
> > > An HFS+ filesystem has a coarse 1s timestamp resolution so that would
> > > explain why the problem shows up there but not systems with subsecond
> > > resolution.
> >
> > Sounds like the correct explanation.
> >
> > > Neither shelve or unshelve appear to use svn_sleep_for_timestamp().
> >
> > Actually shelve already does, in the relevant code path, which is inside
> > svn_client_shelf_unapply() where it uses svn_client_revert4() which does.
> >
> > Unshelve sleeps now, since r1833532. Hopefully that's the end of it.
> >
> > Thank you very much for the insight, Philip!
> >
> > - Julian
>

-- 
- Julian