Bert Huijben wrote:
> Philip Martin wrote:
>> "Bert Huijben" <bert_at_qqmail.nl> writes:
>>> And we use some of this time to see if you have a modern filesystem that
>>> stores more timestamp details than just seconds (by looking at the existing
>>> filesystem node passed to the function) and if you have such a filesystem
>>> we don't sleep at all.
>>
>> We still sleep on filesystems with high resolution but we switch to a
>> millisecond sleep instead of a second sleep.
>>
>> I still think that sleeping when use-commit-times=yes is odd. With
>> use-commit-times=no we know that timestamps set by the operation for are
>> in the past and the sleep takes account of the limited precision. With
>> use-commit-times=yes we simply don't know that timestamps are in the
>> past: they could be years in the past, slightly in the past, slightly in
>> the future or years in the future. Sleeping for 1s, or 1ms, in the hope
>> that it will solve problems with one tiny part of that range when it
>> could also create problems in another tiny part of that range is odd.
The rationale is that the "slightly in the past" scenario (where sleeping helps) is far more likely and worth supporting than the "slightly in the future" scenario (where sleeping hinders) -- for a longer discussion, see my reply to "Re: svn commit: r1464769 ..." a few minutes ago, <http://svn.haxx.se/dev/archive-2013-04/0131.shtml>
> While traversing the working copy we might update the record for files to
> mark/record them as unchanged, even though we didn't write them and
> didn't set the timestamp ourselves. (E.g. files that were merged. Or just
> updated externally)
>
> I don't really care about whether this case is interesting enough to
> perform/not perform the sleep. I try to avoid use-commit-times where
> possible.
>
> And optimizing for this nonstandard setting is not really interesting for
> me. My users usually won't see the sleep anyway.
Right. The whole "sleep for timestamps" functionality is as a rather crude "best effort" attempt to avoid problems, but doesn't address all scenarios. A better solution could be designed, as suggested in issue #4342 "Sleep for timestamps should be determined by libsvn_wc". My recent commits are just fixing up some inconsistencies and oversights in this existing support, and not attempting to address all scenarios.
- Julian
Received on 2013-04-05 17:48:44 CEST