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