On 8 Mar 2002, Karl Fogel wrote:
> I think it won't be necessary to do that. If we have to ask for
> predecessors at all, the number of askings is going to be proportional
> to the size of the change, and having to do a number of DB access
> proportional to the size of the change is no big deal -- I mean, this
> is a *commit*, after all, we just sent the data over the network. :-)
I'm a little nervous about the implications for skip-deltas, assuming we
ever do them (and I hope we do). To do the re-deltifications on a commit,
we need to walk back some number of predecessors from the current
node-revision ID--only two on average, but sometimes a whole bunch. In
particular, at each power of two we re-deltify the oldest revision against
the head, requiring a complete walk of the predecessors back to the root
of the node.
For this kind of operation, it would be most ideal to have random access
to the node-revision ID list for a node, e.g. by forcing the
node-revisions to be 100.1, 100.2, etc.. Forcing that does require the
"stabilization walk" at the end of a commit which we'd like to get rid of,
though.
I guess that could argue for Branko's opportunistic re-deltification
approach, but I don't really like how that approach only yields reasonable
performance the second time you access an old revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 9 22:32:24 2002