Greg Stein <gstein@lyra.org> writes:
> 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?
I'm thinking of `svn log' where the user wants to know changes that
happened to a given node as it currently sits in the directory
heirarchy, and therefore doesn't want to step backward across "copy
history". That is, "show me all the changes to /branches/my_branch,
but not all the history prior to the copy I made to create that
branch."
> 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.
Consistency with the representations and strings tables would be my
reason. The revision keys are the only user-visible keys (node keys,
rep keys, strings keys, and txn ids are not), so those can stay
numeric. In fact, we could make the nodeIDs be base64 as well, now
that I think about it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 10 02:52:39 2002