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

On Aug 31, 2005, at 12:38 PM, Todd A. Jacobs wrote:
>
> This doesn't appear relevent, since the documentation says that
> Subversion assumes midnight *if no timestamp is specified.*
> Clearly, I've specified a timestamp--one matching the logs, in fact.

I think I see the problem: the actual svn:date property attached to
the revision is a 64-bit apr_time_t value. For example, using
subversion's own repository:

$ svn propget --revprop -r16015 svn:date
2005-08-31T13:44:58.539536Z

On the other hand, 'svn log' prints a number rounded off to the
nearest second:

$ svn log -q -r16015
------------------------------------------------------------------------
r16015 | nori | 2005-08-31 08:44:58 -0500 (Wed, 31 Aug 2005)

So, when you provide the same rounded-off date to a subcommand, I'm
pretty sure that it's *also* being converted into a 64-bit time...
one which is exactly at NN.000000 seconds. When compared to the
revision's timestamp, it's almost always going to be smaller, and
thus the "latest revision at time NN.00000 seconds" is the previous
revision:

$ svn log -q -r{"2005-08-31 08:44:58"}
------------------------------------------------------------------------
r16014 | julianfoad | 2005-08-31 08:30:04 -0500 (Wed, 31 Aug 2005)

So perhaps this is a bug, just insofar as it's not doing what the
user expects. Maybe we should file an issue on this? 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...)

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org