Re: svn commit: r1464769 - in /subversion/trunk/subversion/libsvn_client: revert.c switch.c update.c

Julian Foad <julianfoad_at_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