> -----Original Message----- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: vrijdag 27 augustus 2010 14:57 > To: Bert Huijben > Cc: 'Bert Huijben'; 'Greg Stein'; dev@subversion.apache.org > Subject: Re: Two svn_wc__db_t for single-db upgrade > > "Bert Huijben" <b...@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.
But even then, this doesn't fix that we must be able to recover when the upgrade fails. A working copy can never have a wc.db and an entries file. So you would also have to make a svn_wc__db_t that uses something else than '.svn/wc.db', and... and... and... (you are essentially reinventing the kind of hacks we had in WC-1.0, that we try to avoid with WC-NG) I really think that it is much easier to just walk the entries files using an old style-lock, constructing a new sqlite db 'upgrade.db' somewhere outside the normal location using upgrade specific code. Inserting the node data, properties checksums, etc. while walking and adding workingqueue operations as we go for moving the pristine files in place later (and deleting unneeded administrative data). If this step fails you just have to remove the upgrade.db file, because the old working copy is still unmodified. But when this step is finished, you can destroy the top level wcroot and install the upgrade.db as new wc.db file (actions: move wc.db in place and then delete the entries file). You can then fix the rest of the working copy by just running the working queue, which will remove all the 1.6 like markings from all the subdirs and fix the pristine store before the db is ready for usage (normal patter). This step is restartable by calling svn cleanup on the root. Bert