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