In Subversion 1.7 we queued database operations that contained further operations that would change the database further. This left the database in an inconsistent, mostly unsupported intermediate state, which would provide invalid results on certain operations. The cleanup was really required to make the database consistent again.
All these problems were resolved for 1.8.0, but for 1.8 we didn't remove the restriction while we could have done that (stsp wrote that patch some time after 1.8).
The interesting cases are things like recursive base-deletes (part of update processing). In 1.7 that operation is done as many recursive db transactions, which each schedule workqueue items. Since 1.8 there is a single db operation that schedules all workqueue operations, and can never leave the database with a half a base-delete.
When we moved this check I did another carefull check to see if all wq operatios were safe (and I checked the wq operations again short before branching 1.9). I don't see actual cases why we would really need to block out read-only operations any more.
Some write operations certainly need higher guarantees, but that is what the write lock is for.
Bert
Sent from Surface
From: Ivan Zhakov
Sent: Tuesday, May 12, 2015 5:55 PM
To: 'Evgeny Kotkov', dev_at_subversion.apache.org, Stefan Sperling
On 12 May 2015 at 18:28, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, May 12, 2015 at 06:14:16PM +0300, Evgeny Kotkov wrote:
>> Subversion 1.9.0-rc1 changed the behavior of commands such as 'svn st'
>> in situations the wc.db workqueue is not empty, i.e., contains stale items.
>> These read-only commands no longer fail with SVN_ERR_WC_CLEANUP_REQUIRED:
>
>> Any thoughts on this?
>
> r1501338 was never backported to 1.8.x. So far, I hadn't heard a detailed
> explanation of what exactly was wrong -- it was simply .0rejected on grounds
> of being a "destructive change" without further details.
> I've since removed the backport nomination in r1665846.
>
Just to clarify: my concerns regarding r1501338 nomination was mostly
procedural: it was not regression nor critical bugfix. I didn't have
enough time to analyze the change the change itself.
--
Ivan Zhakov
Received on 2015-05-13 02:12:00 CEST