Ben Reser wrote:
> On Tue, Apr 2, 2013 at 1:04 PM, Julian Foad wrote:
>> Philip Martin wrote:
>>> Could we check use-commit-times and avoid the sleep? Either before
>>> sleeping or perhaps where we set sleep_here TRUE.
>> OK, thanks; I did that (inside update_internal()), and a few more things,
>> and committed r1463721.
> I'm not sure this is such a great idea. If you use commit times it
> may or may not be safe to skip sleeping. I discussed this a bit with
> Philip on IRC today where he pointed out sleeping may also in some
> cases may create problems as well.
> Commit timestamps may be in the past or the future.
> If they are less than the timestamp resolution of the file system in
> the past then an immediate change to the file after the command exists
> will not be visible to Subversion. This can be resolved by sleeping.
> If the timestamp is in the future then sleeping may bring you within
> range of the timestamp resolution of the file system, resulting in the
> same problem. The future timestamp problem can be dealt with by
> keeping clocks in sync (NTP).
Yes, we shan't attempt to handle the clock-skew problem at the moment. That is one of the issues that the enhancements suggested in <http://subversion.tigris.org/issues/show_bug.cgi?id=4342>, "Sleep for timestamps should be determined by libsvn_wc" could address.
> It'd be easy to say "If you're doing the type of automation that's
> bound to run into these sorts of problems don't use commit times."
> However, I suspect there's times where you want to do both. As it is
> right now if you're keeping your clocks in sync it should work okay.
> But unless I'm missing something that's not the case after this
That's true, given that the current implementation doesn't look at the timestamps when deciding whether or how long to sleep. So the safe thing to do is reintroduce a sleep even if using commit times, for all applicable operations (checkout, update, switch, revert).
I'll commit this soon. (Running tests now.)
Received on 2013-04-04 22:51:26 CEST