> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 27 augustus 2010 14:57
> To: Bert Huijben
> Cc: 'Bert Huijben'; 'Greg Stein'; dev_at_subversion.apache.org
> Subject: Re: Two svn_wc__db_t for single-db upgrade
>
> "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.
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
Received on 2010-08-27 15:21:07 CEST