Re: Maintaining NodeID sanity

On Thu, May 09, 2002 at 05:34:11PM -0500, Karl Fogel wrote:
>...
> <root>
> / | \
> / | \
> / | \
> A(3.m) B Y(3.p.jfb)
> / \ | / \
> foo bar qux foo bar
> (5.abc) (5.abc)
> : :
> : :
> (5.ejk) (b.mht.jfb)
> : :
> : :
> (5.xyz) (b.uuu.jfb)
> : :
> : :
> (5.r2d2) (b.2pz.jfb)
> : :
> : :
> (5.c3po) (b.rdt.jfb)
>...
> During this walk, you can always tell when you encounter a node that
> results from a copy, because the copyID portion will either change or
> disappear entirely. When this happens, you know one of two things is
> true: either the previous node in the walk was the top of a copied
> tree, or *this* node (the one with the different copyID) was one of
> the unchanged nodes down inside a copied tree.

Why do we care about the status of the child node? Or, to put another way,
why do we generate a new copyID? Isn't it sufficient to just change the
NodeID and leave it at that?

Ah... you use that '.jfb' and the copies table to relate the node to 5.*,
right?

>...

Oh... and why bother with base64? To keep the keys shorter in the DB? That
seems rather obscure. When debugging, I think it will be much nicer for the
humans to just use a plain old integer.

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