"Bert Huijben" <bert_at_vmoo.com> writes:
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
>> Sent: donderdag 26 augustus 2010 16:34
>> To: dev_at_subversion.apache.org
>> Subject: Two svn_wc__db_t for single-db upgrade
>>
>> One of the problems with single-db upgrade is that write_entry, called
>> from svn_wc__write_upgraded_entries, want's to be able to query the
>> new database using things like svn_wc__db_scan_addition. This fails
>> because svn_wc__db_pdh_parse_local_abspath encounters old .svn dirs
>> and creates pdhs with the wrong wcroot.
>>
>> One way to fix this would be to revamp write_entry so that it doesn't
>> need to query the existing database, but that would involve caching in
>> memory some of the stuff we write to the database.
>
> I think this code needs revamping anyway, to properly calculate op_depths
> and other things we need for the 4th tree that will never be returned by
> just calling read_info().
The write code uses _scan_addition() not _read_info(). Why would
those not understand op_depth? They don't at the moment but I assume
they will when NODE_DATA arrives.
> I think the upgrade code should just read the entries in a directory and
> then upgrade the nodes it sees, passing a chain of parent entries (or
> similar) so you never have to rely on the intermediate DB state while
> loading. (This also avoids actively maintaining the upgrade code in future
> versions).
That's creating a database in memory; I'd rather use the proper
database. I don't see why the intermediate state should be a problem,
it may not have all the nodes yet, but the nodes that are present
should be correct.
>
> The normal recursive iterpool pattern should keep the amount of in memory
> data manageable. (Shouldn't be much more than an old svn_wc_walk_entries
> call + the upgrade state).
Yes, caching in memory so as to avoid calling _scan_addition is an
alternative. But it seems odd to cache in memory data that has just
been written to the database. It's all in the database if we want it.
>> An alternative is to use two svn_wc__db_t handles and arrange for one
>> of them to ignore the old .svn directories. The following patch does
>> this and passes the upgrade regression tests (admittedly not much of a
>> test). Does this sound like a good approach?
>
> Thinking about the 4th tree, I think this will work now, but break in only a
> few weeks.
>
> A slightly easier variant (that needs less hacks) might be to create the
> wc.db in a temp directory, like you recently implemented for 'svn copy
> wc-dir wc-dir2'.
I thought about this but I coudn't see how it would work. What might
work is to move all the existing 1.6 .svn into a tree in the root 1.7
.svn directory, but that might cause problems for interrupted
upgrades.
--
Philip
Received on 2010-08-26 17:35:09 CEST