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 > change. 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.) - Julian
