On Thu, 2004-04-22 at 20:33, Branko Èibej wrote:
> The API problem is that svn_repos_dated_revision looks for _one_
> revision using _one_ date. So if your revisions aren't ordered by date,
> you can't just use this function to find the first and last revision in
> a date range and rely on the result. Instead, we need a new function
> that accepts a start and end date, and returns a list of revision ranges
> that fall within those two dates.
I'm not sure what you could do with that information, though. If you've
got mis-ordered dates such that "{2004-10-10}:{2004-10-11}" results in
revs 4, 5, 800, and 6, in that order, what does "svn diff -r
{2004-10-10}:{2004-10-11}" do?
I remain convinced that enforcing date order is the only sane path to
follow.
> The implementation of such a function
> is trrivial and involves only a cursor traverse of the revision index,
> not touching revision props at all.
I've gotten the impression that cursor walks create locking issues in
the BDB implementation. And it's also possible to imagine a repository
getting big enough that a cursor walk of a table containing N revisions
is too expensive, if getting a revision by date is a common operation.
It seems like the best implementation would be a btree database where we
could perform a binary search to find the closest match, and then walk
forward or backward by one key as necessary, except BDB doesn't seem to
have a "get the closest match in a btree database" operation, or a "walk
forward or backward by one key from a specified starting point in a
btree database" operation. Obviously, such a thing wouldn't dovetail
with the revision indexes plan, if we could implement it at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 25 18:10:41 2004