[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Executing 'svn st' with stale wc.db workqueue doesn't fail in 1.9.x

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 12 May 2015 17:24:54 +0000

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.


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

This is an archived mail posted to the Subversion Dev mailing list.