"Bert Huijben" <b...@vmoo.com> writes: >> -----Original Message----- >> From: Philip Martin [mailto:philip.mar...@wandisco.com] >> Sent: donderdag 26 augustus 2010 16:34 >> To: dev@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
