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

Re: svn_io_sleep_for_timestamps not sleeping long enough

From: Branko Čibej <brane_at_wandisco.com>
Date: Tue, 25 Mar 2014 08:31:16 +0100

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
Received on 2014-03-25 08:31:57 CET

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.