> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 27 augustus 2010 11:50
> To: Bert Huijben
> Cc: 'Greg Stein'; dev_at_subversion.apache.org
> Subject: Re: Two svn_wc__db_t for single-db upgrade
>
> "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.
In case of a delete of copy you can have
BASE normal (checked out N levels up)
NODE_DATA normal (descendant of copy 2 levels up)
NODE_DATA normal (child of copy 1 level up)
WORKING: deleted (node itself)
_read_info() will give you the information from working (It is deleted). And
_base_get_info() shows you there was a base in the repository. So you see a
normal base delete using the wc-db api. But actually you have 3 deletes in
one place (one inherited).
The current DB code can only represent the information you get from
_read_info and _base_get_info(), so the rest is lost.
svn_wc_entry_t
however can represent one intermediate layer. Not the two from this example,
but just one. (The other case cannot be created by libsvn_wc. It will say
that you have to commit first).
But even in that case there can be different information in the parent stub
and the child directory itself.
> > 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.
So, we have to add at least one IF that always evaluates to one case for all
future Subversion versions except for upgrading for <= 1.6?
In my book, that is changing APIs just for upgrade.
> 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.
No, (No!)
I already suggested dropping all upgrade support for formats
13-(SINGLE_DB-1) from libsvn_wc and leave that to some hacky python script.
Why would you ever want to use the entry read code via wc__db_t?
You can just read the entry files recursively and insert in the db as
needed. The wc_db api doesn't have to care about entries files at all; only
for detecting that WCs must be upgraded.
Bert
Received on 2010-08-27 12:07:11 CEST