Re: svn_io_sleep_for_timestamps not sleeping long enough

On 24.03.2014 19:47, Philip Martin wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>
>> Philip Martin wrote:
>>
>>> Julian Foad writes:
>>>>> Modify: 2014-03-24 16:40:17.566569826 +0000
>>>>> Modify: 2014-03-24 16:40:17.570569785 +0000
>>>> Is it possible to query the system clock resolution at run time? That
>>>> would seem best.
>>> I believe the system clock resolution is different from the filesystem
>>> resolution.
>> Correct. We need to know both to perform an optimal sleep.
> I don't think the clock resolution tells us much. When I try:
>
> echo x>f && date +'%F %T.%N' && echo y>g && date +'%F %T.%N' && stat f g | grep Modify
>
> I sometimes get output like:
>
> 2014-03-24 18:38:41.600661633
> 2014-03-24 18:38:41.601409267
> Modify: 2014-03-24 18:38:41.596646220 +0000
> Modify: 2014-03-24 18:38:41.596646220 +0000
>
> So the files f and g have the same timestamp even though date between
> the two writes shows two different, later, times. In this case any
> check comparing 'now' to the first file would indicate that 'now' is
> later than first file, but the second file still gets the same timestamp
> as the first file.

I would guess that the easiest way to solve this would be to
periodically touch and stat the WC root dir until its mtime changes.
Unfortunatesly, sleep-for-timestamps has not the slightest idea where
the WC root might be ...

This would still leave us open to the weird case where parts of the
working copy are bind-mounted to a different filesystem, but I'm quite
happy to ignore that edge case; solving it would require storing the
equivalent of a device number for every directory in the working copy.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com