On Tue, Apr 2, 2013 at 1:04 PM, Julian Foad <julianfoad_at_btopenworld.com> 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).
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
change.
Received on 2013-04-03 02:13:53 CEST