Re: RFC: Revision indexes for 1.1

On Sun, 2004-04-25 at 12:53, Branko Èibej wrote:
> >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?

> You seem to be forgetting that we also filter by path, not only by date.
> The client needs an intersection of the set of revisions in which a
> subtree changed, and the set of dates belonging to a range.

So, what happens if I run that command on the root of the repository?
Your heuristic analysis doesn't seem very convincing to me; you seem to
be saying "eh, people probably won't run into the hard cases very
often."

> >I remain convinced that enforcing date order is the only sane path to
> >follow.

> If we keep that restriction, there's no way optimize cvs2svn, which
> means that people who start with a converted repository will keep
> complaining about the size blowup.

I have a hard time believing this, but I'm at a bit of a disadvantage
since I don't follow cvs2svn development. Perhaps you can spell out
where the conflict lies.

> >I've gotten the impression that cursor walks create locking issues in
> >the BDB implementation.

> I can't believe BDB needs more than two lock object to do a linear
> cursor walk, unless you do the walk in a transaction. And there's no
> need to do that, it being a read-only operation.

But there might be write operations mucking with the table at the same
time, and they need to do so in a transaction.

> > 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.

> You obviously don't walk the whole table; you start with the smallest
> matching index and stop when you've passed the largest one.

You've lost me, a bit. Were you proposing that the revision indices
would all be btree tables?

> > except BDB doesn't seem to
> >have a "get the closest match in a btree database" operation

> Huh? DBcursor->c_get with DB_SET_RANGE

Ah, good to know.

> Not to mention that it takes a single SQL query. But it might be a bit
> hard to do in libsvn_fs_fs, I imagine. :-)

It's true, your revision index feature is difficult (though I think not
impossible) to implement within a libsvn_fs_fs design, and since I
continue to think that it's of minimal value in general, I'm not very
fond of it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 25 19:18:47 2004