Re: "svn diff" and "svn log" timestamp weirdness
Michael Sinz <[email protected]> Wed, 31 Aug 2005 16:04:37 -0400
| Newsgroups | gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected] My place on the web http://www.sinz.org/Michael.Sinz