Michael Brouwer wrote:
> What might be even better is to always do a less than with the value
> the user specified plus 1. If the date is the end of a range. And a
> greater or equal of the specified value with all unspecified fields set
> to 0 if the date is at the start or a range.
>
> For the end of a range this would mean:
>
> -r{2005} would find the first date < 2006
> -r{2005-05} would find the first date < 2005-06
> -r{2005-05-12} would find the first date < 2005-05-13
> -r{2005-05-12 07} would find the first date < 2005-05-12 08
> -r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
> -r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
> -r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
> 07:13:12.23
As nice as this is (and glossing over whether the change in behavior is
"fixing a bug" or not), it is still not deterministic. If there are
more than one revisions with a timestamp in the implicit range, which
one is most appropriate to return? The date search algorithm performs a
binary search, so you cannot just stop searching at the first revision
that appears to match, you'd need to switch to a linear search and
collect together the possible revisions.
I think your basic suggestion is good, but it needs a firm definition of
which revision would be returned of multiple possible returns. To use
series notation, I would think the first record that falls in the [time,
time+1) range would be most likely what the user would expect. The
binary search could find any revision in that range, then step backwards
exclusively to find the smallest revision that satisfies the range. But
at least as good an argument could be made that the largest revision
that satisfies the condition is just as correct.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 1 18:00:18 2005