Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 24 Jul 2017 18:34:29 +0200
From: Stefan Sperling <stsp@elego.de>
To: Daniel Shahaf <d.s@daniel.shahaf.name>, dev@subversion.apache.org
Subject: Re: default mode of 'svn cleanup' changed
Message-ID: <20170724163429.GF90677@ted.stsp.name>
Mail-Followup-To: Daniel Shahaf <d.s@daniel.shahaf.name>,
	dev@subversion.apache.org
References: <20170724120913.GB90677@ted.stsp.name>
 <1500910832.650285.1050829952.55F2721E@webmail.messagingengine.com>
 <20170724162210.GE90677@ted.stsp.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170724162210.GE90677@ted.stsp.name>
User-Agent: Mutt/1.8.0 (2017-02-23)
archived-at: Mon, 24 Jul 2017 16:36:16 -0000

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.