Branko Čibej <brane@xbc.nu> writes:
> > (svn_fs__open_reps_table): Initialize the "next-key" entry.
> >
>
> I wonder why you're doing this? Why are you using a B_TREE table for
> the reps, and generating your own sequential keys, instead of just
> using a RECNO table and letting DB take care of that? The "revisions"
> table does that, for instance. It's not as if you need some magic key
> structure, like in the nodes table. You won't be doing any range
> searches in the keys.
>
> (Come to think of it, the "transactions" table could be a RECNO,
> too. Hmm. Am I missing something?)
I was worried about the sheer numbers, and debuggability.
The growth of the revisions table is much slower than the strings or
reps table. For each revision, there will probably several new
strings and reps, not to mention the key ranges lost when a
transaction is aborted or whatever (something which will require a few
more tweaks to the plan in `structure', to allow us to remove the new
reps and strings while not removing shared ones, but that's another
matter, so never mind now. Do record deletions affect RECNO
performance adversely, by the way?).
So partly it was to save on key length and increase the available key
space. But also to make debugging easier. Sometime in the near
future, a human (me, you, Mike Pilato) will be mentally tracking
various keys in strings and reps while trying to debug some awful
problem. Personally, I find combinations of letters and numbers a lot
easier to recognize and match with each other than straight numeric
keys.
Not very aggressively defending the decision, mind you :-), just
explaining why I didn't go for RECNO. If there's no huge loss to
doing it this way, I'd like to stick with it.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:32 2006