I'm with Bert. The entry writing is used *only* for upgrades. It may
as well be tuned for exactly that: track any information you need
while performing the upgrade.
Also remember that the wc.db file that is being constructed during the
upgrade process really should be called something like wc.db.upgrade
(see SDB_FILE and SDB_FILE_UPGRADE). We just aren't doing that right
now. And what *that* means is that the wc_db functions will not work
during the upgrade process. And really: you shouldn't rely on them.
You're in a transient state, trying to build a proper database.
Cheers,
-g
On Thu, Aug 26, 2010 at 10:58, Bert Huijben <bert_at_vmoo.com> wrote:
>
>
>> -----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().
>
> 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).
>
> 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).
>
>> 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'.
>
> Bert
>
>
Received on 2010-08-26 19:39:06 CEST