[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: Greg Stein <gstein_at_lyra.org>
Date: 2002-05-10 22:46:38 CEST

On Fri, May 10, 2002 at 01:39:03PM -0700, Greg Stein wrote:
> On Fri, May 10, 2002 at 03:07:31PM -0500, Karl Fogel wrote:
> > - 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.

And I'll further point out that the new ID structure (in id.h) would be:

struct svn_fs_id_t
    apr_uint32_t nodeID;
    apr_uint32_t copyID;
    apr_uint32_t txnID;

To put strings in there will just screw up the FS. All of your comparisons
would become more difficult and take longer.

> > 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 :-)

Oh. Using base64 (strings) would be a negative system perf change, given the
ID comparison pointed out above.


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 Fri May 10 22:45:31 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.