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

On Aug 31, 2005, at 8:50 PM, John Peacock wrote:

> Justin Erenkrantz wrote:
>
>> I agree [with] Brane and Michael: fix the UI to return it over the  
>> implicit period in question.  Removing any level of precision in  
>> the repository from what APR produces (64-bit microseconds) gets a  
>> -1 from me too.
>> (There were lots of heated debates over 'time' in APR.  Ugh.)  --  
>> justin
>>
>
> I'm resigned to lose this argument.  Correct handling of time  
> values arouses passion in the few people who understand how  
> thoroughly broken default implementations are currently.  I've  
> fought this before (and probably will again).

Trying to get back on track here...

So the original "bug" was that from the user's point of view, it  
looks like there ought to be a 1 to 1 mapping between the dates 'svn  
log' displays and the dates one can specify with -r{DATE}.  But in  
fact, there isn't a direct mapping, due to rounding to the nearest  
second.  If 'svn log' says that rN happened at time "2005-08-23  
00:14:17", when the user types -r{"2005-08-23 00:14:17"}, he gets r 
(N-1) back, because it turns out that the commit-time is actually  
recorded as 00:14:17.23983.

Are you guys suggesting, therefore, that

       -r{"2005-08-23 00:14:17"}

...actually be interpreted as if the user had typed

       -r{"2005-08-23 00:14:17.00"}:{"2005-08-23 00:14:18.00"}

?

The result might be a range of revisions.  This is all fine and good  
for 'svn log', but a lot of commands don't take revision ranges.   
What do we do then?


-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand