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