[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Two svn_wc__db_t for single-db upgrade

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 27 Aug 2010 13:57:08 +0100

"Bert Huijben" <bert_at_qqmail.nl> writes:

> But even in that case there can be different information in the parent stub
> and the child directory itself.

That's why I want to use the database.

>
>> > 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
>

-- 
Philip
Received on 2010-08-27 14:58:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.