John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> I suppose we could either (A) always store the svn:date property
>> rounded off to the nearest second, or (B) when loading the svn:date
>> property for comparison purposes, round it off to the nearest second
>> (this would be in our rev_hunt() binary search algorithm...)
>
> My 2 cents:
>
> A) is better in the long run, because it doesn't perpetuate the illusion
> that computer clocks are that accurate unless you are regularly syncing
> with a reference clock; I've seen drift rates of seconds to minutes per
> month. Just because someone decided to provide nanosecond precision
> doesn't mean that your computer can provide meaningful data at that
> level. Precision != accuracy.
No - I would *not* want to have the times on the server cut off to a
low precision just because some servers may not have good clocks.
But if you run a server and are not running ntpd then you are asking for
problems. (especially when trying to track down networking
related issues - you want your clock as accurate as possible)
With many developers hitting the same server, it is possible to have more
than one commit per second. Don't throw away data.
> B) is better for compatibility purposes, since it ignores existing
> subsecond precision.
This is much better - have the UI (or whatever you what to call it)
be the place where such rounding and "fuzzy" comparisons happen.
> The best solution is to do both now; round to seconds when comparing,
> but stop storing subsecond precision. When 2.0 comes out, change the
> search code to stop rounding and perform a last rounding when updating
> the repository.
I would very strongly be against anything that reduces the precision of
the data on the server. If the server's clock is not accurate, then that
is not Subversion's fault. Let the server admin fix it (or buy a better
server or...) Chopping off precision just because some user interface
issues due to too much precision is wrong. Just make the UI smarter about
how to deal with that. You can always change, enhance, etc. that behavior
if the data is there. If you don't have the data, you now have lost
the ability to ever expand into, say 1/10 second or 1/100 second or whatever
resolution you might think is reasonable.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 31 22:09:20 2005