[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-11 22:11:07 CEST

Karl Fogel <kfogel@newton.ch.collab.net> writes:

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

Greg has made two arguments against base36: translation-speed and
obfuscation. He even says that above.

However, I don't think I agree with Greg. I don't believe that
translation-speed is an issue at all when we're talking about
disk-bound DB lookups. It's a drop in the ocean.

Obfuscation is the only real issue here, it seems. The silly thing is
that Karl and Greg are each accusing one another of it!

  - Greg argues that the txn-ids are integers, so programmers will be
    *syntactically* confused when we make them look like weird base36
    strings.

  - Karl argues that integers imply ordering of txn-ids, so
    programmers will be *semantically* confused when they they seem to
    be out-of-order.

My vote goes with Karl, because I thing semantic confusion is much
worse. Coders are more likely to poke around the fs and try to
understand the semantic structure of trees. I don't know why they'd
care exactly what data-type a txn-id "really" is... they'll just be
treating txn-ids like opaque blobs anyway.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 11 22:14:52 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.