RE: svn commit: r1371831 / The idea behind the workqueue

> -----Original Message-----
> From: pburba_at_apache.org [mailto:pburba_at_apache.org]
> Sent: zaterdag 11 augustus 2012 00:19
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1371831 - in /subversion/branches/inheritable-
> props/subversion: include/private/ libsvn_client/ libsvn_wc/
> tests/libsvn_wc/
>
> Author: pburba
> Date: Fri Aug 10 22:18:59 2012
> New Revision: 1371831
>
> URL: http://svn.apache.org/viewvc?rev=1371831&view=rev
> Log:
> On the inheritable-props branch: Atomically update cached iprops with
> work queue items during update/switch editor drives. Remove the
> temporary
> svn_client__update_inheritable_props API.

Delayed review, as I didn't feel like typing this on my phone a few weeks ago, and I don't think this had to be solved soon.

As a temporary api I don't see a problem with this, but I would recommend *not* using workqueue items for just updating wc.db. Especially if you can do the same work in the same db transaction as the primary operation. The workqueue's task is just keeping the database and in-working copy data in sync.

Delaying the operation to a workqueue operation leaves the database in an 'in-between' stable-states and running the workqueue for such an operation requires at least 3 additional database transactions before the database is stable again.
I just finished removing the last of such states before I left for vacation. (We still had a few of such operations left over from the old loggy behavior)

And not using a workqueue operation also makes it easier to change the way we handle this in the future. Once we release a Subversion version with some workqueue support 'all future versions' should support running this workqueue item.

For now I would recommend just going on the way you started... we can fix this before branching.

        Bert
Received on 2012-08-21 13:38:35 CEST