Greg Stein <gstein@lyra.org> writes:
> > <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?
Goodness me, what a confusing typo I made.
All those "b.*.jfb" should be "5.*.jfb", sorry for the confusion!
> 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.
It's just to avoid the endless questions from people worried about
running out of keys :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 10 21:49:54 2002