> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: donderdag 26 augustus 2010 21:33
> To: Greg Stein
> Cc: Bert Huijben; dev_at_subversion.apache.org
> Subject: Re: Two svn_wc__db_t for single-db upgrade
>
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > [I'm aware that we don't add incomplete children when we add a
> > complete parent, but the children don't care about siblings. And it
> > should be easy to fix.]
>
> Turns out we do this the right way. We add a parent, and incomplete
> directory children (plus any files) in a single transaction, then we
> move on each directory child and do the same again.
Yes, we do this *right*, but only in the *easy* cases.
The hard cases, like missing and obstructions of metadata are not handled
and cannot be handled by the single-db WC-DB api as these cannot occur there
. (There are no tests for this, and anything that looks like a test for this
is disabled for some 4th tree reason). You can't even see that data is
missing from most of the wc-db apis at they fall back to the parent stub.
(And the wc-db api doesn't allow annotating a node that it misses some
information)
I don't think we can ever handle all the upgrade state with just the
single-db optimized API.
E.g. by just using the API you can't look through child-of-copy deletions,
nor do we need any apis for this for 1.7. But svn_wc_entry_t just has this
information directly.
So you are suggesting that we change the DB API's to provide this
information (or keep providing this multi-db specific information like the
obstruction statee that really have to be removed to get back at 1.6 speed),
while we will never need these functions and statee after this conversion to
single-db?
Using the db api for intermediate storage during update is making things
harder for future api users that never want to look back at the
pre-single-db era.
And it slows down common code paths just to support upgrading from a version
that is hopefully ancient for us in a few months.
And then we can only fix the api by fixing this problem later... or by
moving to wc-ng-NG.
Bert
>
> --
> Philip
Received on 2010-08-26 22:01:40 CEST