[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 05 Apr 2013 17:13:44 +0100

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:
Received on 2013-04-05 18:14:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.