[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-08-31 20:26:40 CEST

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

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

$ 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
Received on Wed Aug 31 20:29:31 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.