Re: "svn diff" and "svn log" timestamp weirdness
"Todd A. Jacobs" <[email protected]> Fri, 2 Sep 2005 01:31:32 -0700
| Newsgroups | gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <20050902083132.GA6088__2535.27190438962$1125652547$gmane$org@penguin.codegnome.org> |
On Thu, Sep 01, 2005 at 10:46:59AM -0400, Michael Sinz wrote: >So, maybe the client could always take the time and if use specified to >the second it would add in 0.9999 seconds such that any missing >sub-second value would be handled in the way the user expects. I've watched the thread develop, and have a few thoughts. Firstly, the easiest solution is probably to *truncate* log times, rather than the current rounding. Truncating the log entry to "21:18:07" from "21:18:07.99998" instead of rounding up to "21:18:08.00000" would at least avoid situations where there was no matching record *at all* for the given time period, or erroneously returning results from a future time period. However, as another poster mentioned, the fact that subversion *assumes* that one wants the latest revision for a given time period is at least a valid point of discussion. If I wanted the revision from "yesterday," I probably would want the latest revision during that period. But if I ask for the revision from 14:35 today, I should probably be informed if there were 7 other commits during that one-second period, since the one returned (the latest) may not actually be the one I *think* I'm asking for. The goal of returning the latest revision is obviously to reduce the burden on the end-user. It's good goal. But it *may* violate the principle of least-surprise from time to time. -- Re-Interpreting Historic Miracles with SED #141: %s/water/wine/g