On Tue, Jun 29, 2010 at 13:44, Philip Martin <phi...@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. Cheers, -g
