On Fri, May 10, 2002 at 11:43:00PM -0500, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > struct svn_fs_id_t
> > {
> > apr_uint32_t nodeID;
> > apr_uint32_t copyID;
> > apr_uint32_t txnID;
> > };
>
> Also, Greg, you argued for txn keys to be base36 when you were here in
> Chicago last. Well, not "argued", because we all agreed with you, but
> you were in fact the person who emphasized it first.
Wha??!?! Um, no. If I *really* did, then I was smoking crack because that
certainly isn't what we want to build.
Base-36 (or your suggestion for base-62) is way beyond the insane.
Completely non-standard in all respects, none of the speed Brane was talking
about with base-16 encoding, and still obfuscates the underlying integer
that these keys are derived from.
> The reason was that more txns get created than stay around
> permanently. We use them for updates, also failed commits (perhaps
> due to conflict) happen. A busy repository will eventually make it
> into high numbers. Running out of integers is a danger, and anyway
> the numbers will start getting long sooner rather than later.
Work out the math. If you manage to *sustain* one per second, you've got 136
years worth (unsigned 32-bit number). You'll definitely burst at times, but
a sustained rate of one per second, year after year, is absolutely amazing.
Running out is simply not going to happen. If there is any possible scenario
where we believe that 4 billion transactions will actually occur, then hell:
make it an apr_uint64_t.
But when you've got these things in memory, they should be integers. Plain
and simple. I'm a bit less concerned about their marshalling into the BDB
records; I think they should be base-10 to simplify everything, but I can
see Brane's position about using base-16 as a quick way to (un)marshal
between memory and BDB.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 11 08:08:50 2002