On 26.08.2010 22:00, Bert Huijben wrote: > > >> -----Original Message----- >> From: Philip Martin [mailto:philip.mar...@wandisco.com] >> Sent: donderdag 26 augustus 2010 21:33 >> To: Greg Stein >> Cc: Bert Huijben; dev@subversion.apache.org >> Subject: Re: Two svn_wc__db_t for single-db upgrade >> >> Philip Martin <philip.mar...@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. >
I'm beginning to wonder what all this fuss is about, though. We're talking about converting the working copy ... and converting only on one direction, from multiple to single-db WC, never the other way. First of all let's not loose sight of the fact that a WC can be reconstructed from the repository. But since that's not always a welcome alternative, does the upgrade process really need to handle all the zillions of half-baked states that a working copy can have? And another question, does the upgrade functionality really belong into the svn binary, or even libsvn_wc? Because there's sure to be functionality in there that will only ever be used by the wc-db upgrade, i.e., only in versions 1.7 and 1.8; so why not make the upgrader a separate binary, with the messy parts of the DB handling done there instead of polluting the longer-lived part of the code? (Also I'm not quite clear here on the feature set for 1.7 ... if we intend to release with single-db support, then why support multi-db at all, except perhaps for detaching parts of the working copy?) -- Brane