On Tue, Jun 29, 2010 at 13:44, Philip Martin <philip_at_codematters.co.uk> wrote:
> Then the automatic upgrade process for 1.7 working copies should be
> changed so that it only runs if the workqueues are empty. If there
> are outstanding workqueues the user is forced to run "svn cleanup".
I've thought about this before, and I disagree.
The code that runs the workqueues is "today's" code. It may not
operate against an old working copy. The upgrade must happen before
the code can properly function. (or we start making *everything*
understand all versions of the working copy)
The position that I've been assuming is that an upgrade process may
need to alter outstanding workqueue items.
For the text-base upgrade, you could fail on a PRISTINE insert if it
exists already and skip the text-base move (on the assumption that a
"move" workqueue item was installed at the same time as the row).
If two files in the working copy have the same checksum, then no
biggy. You don't need to move two files into the same pristine store.
Just one is needed.
All this said... I'm not sure when you plan to run the workqueue.
upgrade.c is not passed the DB by design (just the SDB). The upgrade
process occurs before the DB is "open" (and is therefore not truly
usable). After any upgrade occurs, we examine the workqueue.
Generally, we do not allow the DB to be opened when wq items are
present (the wc is in an inconsistent state).
This is why the upgrade process performs all the filesystem operations
itself, instead of queueing work items.
Received on 2010-06-29 21:23:13 CEST