On 28.05.2013 12:54, Philip Martin wrote:
> Tobias Bading <tbading_at_web.de> writes:
>
>> On 27.05.2013 16:12, Tobias Bading wrote:
>>> On 27.05.2013 16:01, Branko Čibej wrote:
>>>> Can you try this: run the following command for a couple of seconds, it
>>>> should give you an idea about the system clock precision.
>>>>
>>>> { while true; do date '+%M:%S.%N'; done; } | uniq
>>> Redirected to a file, I get about 1250 unique timestamps per second, nicely distributed it seems.
>> Hmm... a modified version of your command paints a completely different picture:
>>
>> { while true; do touch t; ls -l --full-time t; done; } | uniq
>>
>> prints exactly *two* lines per second, one every 0.5 second, exact down to the millisecond.
>> No idea why yet, but this explaines everything I guess. Asking Google...
> An earlier mail showed us that you are using ext4 on OSX -- does OSX
> have native support for ext4 now or are you using a 3rd party driver?
>
> Subversion assumes that a sub-second timestamp implies at least a
> millisecond resolution but that is not the case on your ext4 filesystem.
> We would need to modify the sleep algorithm if we are to support this
> filesystem.
>
> We could modify the sleep calculation to something like:
>
> if timestamp has sub 1ms component
> sleep for 1ms
> else if timestamp has sub 10ms component
> sleep for 10ms
> else if timestamp has sub 100ms component
> sleep for 100ms
> else
> sleep for 1s
What we /should/ do is create a tempfile and keep changing and stat'ing
it until its mtime changes. We could do this with an exponential backoff
sleep, too. Then there would be no guesswork about the timestamp
resolution of the WC file system.
The problem is that we don't always get a path into
sleep_for_timestamps; but we already have a fallback for that.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-05-28 14:43:34 CEST