"Bert Huijben" <bert_at_vmoo.com> writes:
> 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.
The upgrade code only ever needs to use the database to look at
parents. If the parent information in the database is not correct
then the upgrade has already failed.
I don't understand your child-of-copy deletion example. That's one
case the the existing multi-db upgrade code gets wrong, it creates a
base_node where there should only be a working_node. It gets it wrong
because svn_wc_entry_t does not have the copied information. The
information is in the database and can be obtained by calling
_read_info. Or we could make our own in-memory database of entries
and query that, but I don't see why that is better.
> 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.
I'm not proposing to change any APIs. I introduce a new API to allow
the creation of svn_wc__db_t that ignores 1.6 .svn directories when
constructing pdhs. That's the only change. It allows the existing
upgrade code to work in single-db just as it works in multi-db, with
the same features and bugs.
Just had a thought. Do you think I am proposing that we extract
svn_wc_entry_t structures from the database during upgrade? That's
not what I am proposing. Upgrade will read the 1.6 .svn/entries to
get svn_wc_entry_t structires, but when we need information about the
parent we use the existing wc-ng API to get things like
svn_wc__db_status_t.
--
Philip
Received on 2010-08-27 11:50:39 CEST