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? 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. I still think it's odd to sleep when use-commit-times=yes but not enough to change it :) > Does this make sense now, and how can I change the log message wording > to clarify and so it doesn't misrepresent you? The log message is OK. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
