> From: Bill Tutt [mailto:billtut@microsoft.com]
>
> Mike wrote:
> > Another concern was mentioned by Ben, and I think I echo the same
> > concern. Namely, are the additional `changes' table items for
> > bubble-up directories a necessity or an optimization? If they are
an
> > optimization, I'd like to discuss whether that optimization
outweighs
> > the costs: a one-time dump/load cycle requirement, but then a
> > tremendous bloat in the size of the changes table itself.
>
> As near as I can tell atm, it's a necessity. get_id_path can't make
up
> data that doesn't exist in the change table. Additionally, get_id_path
> can't do a substring compare on the paths it does locate because
that's
> the whole point in calling get_id_path. i.e. to get the offical
committed
> path of a NodeRevision, and not to guess at what it was.
>
There are optimizations to be had in the patch itself, but there aren't
any about not having that data there.
The easiest way to help yourself see what's going on is to comment out
the additional add_change calls, and see how various fs-tests begin to
fail by open_path incorrectly determining the last branch id due to the
incapability of determining the committed path.
It might be that you could alter the open_path/is_child_lazily_copied
code in such a way that allows the existing tests to succeed, but I'm
sure you might begin to see alternate test cases that might end up
causing problems.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 1 23:57:51 2002