On 26.08.2010 22:00, Bert Huijben wrote:
>
>
>> -----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.
>
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
Received on 2010-08-27 01:10:14 CEST