[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Todd A. Jacobs <nospam_at_codegnome.org>
Date: 2005-09-02 10:31:32 CEST

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

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
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 2 11:14:43 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.