[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Maintaining NodeID sanity

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-05-11 21:54:28 CEST

Greg Stein <gstein@lyra.org> writes:
> > 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.

Oh -- hunh, I do remember it pretty clearly, but since you don't
really hold that position, it probably means I misunderstood what you
were saying at the time.

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

Base 36 is what I'd like to do; I've already presented the reasons.
Calling it "way beyond insane" doesn't add any substance to the

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

This is not "amazing" at all. Not only humans use repositories; other
programs will start using them too. And Moore's Law still held last
time I checked. Why not make *sure* the problem is solved, once and
for all? It's trivial for us to do -- I know, because I did it for
txns already and it was no effort -- it doesn't affect performance in
any meaningful way, and (for me at least, don't know about others)
improves maintainability by not implying ordering when there is no
ordering going on, and by making IDs a bit more readable.

When the designers of IPv6 considered network address allocation
(which was already supposed to be more than enough at 32 bits, years
ago when IPv4 was designed), they jumped all the way to 128 bits,
wisely skipping 64. They realized that the *rate* of consumption can
increase unexpectedly -- since it already happened once, as everyone
and their toaster started wanting an IP address. (Nevertheless,
within our lifetimes I expect to see debates about how to handle the
impending exhaustion of 128 bits.)

+1 on base36 with `const char *'; -1 on integers whatever the

I believe we've both presented our complete arguments for and against.
If you have something new and constructive to add, please do! FUD
like "way beyond insane" and "completely non-standard in all respects"
doesn't count :-).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 11 21:55:22 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.