Philip Martin wrote: > Julian Foad <julianf...@btopenworld.com> writes: > >> * Near past: The recorded commit time, compared with the client-side >> clock time, is within the timestamp granularity and in the past. >> >> - We do need to sleep. >> - My earlier commit eliminated the sleep, which broke this case. >> - This commit fixes this case. >> >> That second scenario is likely after a commit from the local client, >> and when doing rapid work across multiple clients, assuming the >> client(s) and server clocks are sufficiently well synchronized which >> seems a reasonable assumption if you expect that sort of thing to >> work. > > How are the people using use-commit-times=yes synchronizing clocks?
NTP or similar mechanisms, I assume. > I would suspect that some (lots?) don't do anything and have large skew. > I also suspect most users get the 1ms sleep these days and so even those > that do synchronize won't get much benefit from sleeping. I run ntp on > my machine and it currently reports an estimated error of about 7ms. > That's not good enough for sleeping to work when the sleep is only 1ms. Fair point, so it won't significantly help people who get a 1ms sleep. My "near past" argument above works for people who get a one-second sleep, such as myself, assuming synchronization to within a fraction of a second. > I still think it's odd to sleep when use-commit-times=yes but not enough > to change it :) I agree it's odd, but without a substantial re-work to note the actual timestamps that we're recording (in libsvn_wc), the best we can do is choose either to sleep or not to sleep. To summarize how we're leaving it now, we're calling the sleep function regardless of use-commit-times setting, for all commands that sleep. Compared with how it was before my two commits, the only change in this respect is removing the exception that previously 'revert' was skipping the sleep if using commit times, while the other operations were sleeping regardless. - Julian
