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