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

Re: "svn diff" and "svn log" timestamp weirdness

From: Aaron Wood <woody77_at_gmail.com>
Date: 2005-08-31 23:41:22 CEST

On 8/31/05, John Peacock <jpeacock@rowman.com> wrote:
> You misunderstand. I'm saying _all_ normal server hardware clocks,
> regardless of whether the machine is synced via NTP or some other
> superior method (like taiclock), lack the accuracy to justify the amount
> of precision allocated. The crystals used in conventional computer
> hardware just aren't all that accurate. And depending on your O/S, your
> clock could use skew or step to adjust time with an external source,
> which adds additional noise to the timestamp.

The timestamps are all set on the server, correct?

If so, then on unix, (If I understand 'nix time engines correctly)
later is always later, so while the timestamp may contain a fictional
level of accuracy, it's still precise for what it needs to be (later
is actually later). On windows, you can actually get some really ugly
time movements as it doesn't have "time-warping" ability that I
beleive all 'nix variants use to keep time flowing smoothly.

So, while the bottom bits of the timestamp are roughly irrevelant
noise, the 64-bit timestamp allows for an easy to manipulate timestamp
for comparison purpose. At least easier than intermediate sizes like
48 bits.

I'm not an expert on how the system works, but from this thread, it
appears that it's using a standard 64-bit time format. Which if so,
makes a lot of sense, even if the low bits appear to be noise. The
higher order bits still ensure that the comparisons make sense.
Simply masking out the lower bits also implies some knowledge of when
the accuracy of the clock is to be suspect, and opens up the problem
that in 5 years, we DO have clocks that are an order magnitude more
accurate, and we end up with resoution problems caused by faster
hardware being able to do multiple commits per ms.

We're not far from that now, where my previous desktop was easily able
to do ~10ms commits on a harddisk. Add in a RAID array that has a
battery-backed cache, and commits become VERY fast for some systems.

The extra precision is unecessary now, but may not be in a relatively
short time, especially considering how long CVS has been in use.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 31 23:49:24 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.