Ben Collins-Sussman wrote:
> 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...)
Actually, the bug lies in the fact that we try to select one revision
for any particular time. Even if we round off the timestamp for the
search, or even store the rounded value in the repository, it's quite
probable that several revisions will fall within the one-second interval
in busy repositories (it probably happens in the ASF repo, for example).
If you want to be perfectly correct (not perfectly precise), you have to
return the range og revisions that falls within the precision of the
timestamp given in the query. So, "svn log -r{yesterday}" should give
you a log of all commits made yesterday, not just the one revision where
we happen to decide yesterday started.
-1 on changing the way we store timestamps or the search algorithm,
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 31 21:29:14 2005