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

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.

B) is better for compatibility purposes, since it ignores existing 
subsecond precision.

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.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748