On Mon, Jul 24, 2017 at 06:22:10PM +0200, Stefan Sperling wrote:
> On Mon, Jul 24, 2017 at 03:40:32PM +0000, Daniel Shahaf wrote:
> > It seems the real fix would be figuring out a way for 'cleanup' not to
> > break all locks it sees.
> Actually, I missed that cleanup_internal() grabs a WC lock, so the
> entire point of my argument is moot. The other client manipulating
> WC state will error out if it runs any DB operation after 'cleanup'
> has stolen the lock.
> So I guess I'll just revert my commits :-)
Responding to myself: The only problem which remains is that the user
is currently being given no choice to either steal locks or vacuum pristines.
They can only run these operations in combined form.
Daniel, I'm thinking that reverting r1802797, which changed the default
behaviour of 'svn cleanup', may be good enough to address your backwards
compat concerns, while still giving people a choice to remove pristines
without risking a disturbance of other active clients.
Received on 2017-07-24 18:36:20 CEST