> -----Original Message----- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: vrijdag 27 augustus 2010 11:50 > To: Bert Huijben > Cc: 'Greg Stein'; dev@subversion.apache.org > Subject: Re: Two svn_wc__db_t for single-db upgrade > > "Bert Huijben" <b...@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