Re: Maintaining NodeID sanity

On Fri, May 10, 2002 at 03:07:31PM -0500, Karl Fogel wrote:
> cmpilato@collab.net writes:
> > Seriously, who cares? With the exception of the revisions, these
> > things are never anything bat const char * values, so they can be whatever
> > we want (as long as we can definitively answer the is-greater-than
> > question). Whatever, I'm not personally sold on either way.
>
> I care a bit -- I'd prefer base64, for two reasons:
>
> - Integers imply ordering. But we're not comparing these keys for
> ordering (there's one rare circumstance where we could do so with
> copyIDs, but we may not even use it). We're using them as unique
> keys, period. To use integers would be misdocumenting.

But they *are* integers. That is the point behind the "next-key" stuff. An
integer sits in there, and it gets incremented. Applying a transformation to
that value is obscuring its origin.

The base64 values also have an ordering (ever hear of strcmp() ?). So this
point doesn't really seem to apply.

We've got unordered keys. Period. You don't need to obfuscate their origin
in an attempt to "enforce" the concept of unorderedness.

[ and when moving to SQL, the replacement for "next-key" will (almost
  always (impl. dependent)) generate integers ]

> - As a developer debugging the code, it's easier for me to
> recognize and remember shorter strings in an alphabet with more
> symbols, than longer strings in an alphabet with fewer symbols.
> Long strings of numbers start to look all alike pretty quickly
> (at least to me).

That is FUD, too. "abcdef" and "abcdeg" look awfully the same, too.

> I also feel more comfortable knowing that the length grows so much
> more slowly, but I think that's probably just superstition.
> Nonetheless, it can't *hurt*, right :-)?

Yes, that is superstition. The different between itoa() and a base64
encoding is three digits once you finally reach the billion mark. Down in
the first hundred thousand, you're talking three versus five digits. That
length difference is so negligible from the system standpoint, that it
shouldn't even be considered :-)

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