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

RE: svn commit: r1398389 - in /subversion/trunk/subversion: include/ libsvn_client/ libsvn_subr/ libsvn_wc/ svn/ tests/libsvn_wc/

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 16 Oct 2012 17:50:37 +0200

> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 16 oktober 2012 17:06
> To: Johan Corveleyn
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1398389 - in /subversion/trunk/subversion:
> include/ libsvn_client/ libsvn_subr/ libsvn_wc/ svn/ tests/libsvn_wc/
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
> > With this new "exclusive" mode it's probably quite clear (no
> > parallellism possible at all), but because of the fuzzyness of the
> > non-exclusive behavior this leaves me wondering: "which things does
> > this exclusive mode make impossible, which were still possible under
> > non-exclusive mode"? What does one lose by enabling exclusive mode?
> A write operation like "svn up" opens the working copy and then executes
> a number of SQLite write transactions. SQLite will block other reads
> while a write transaction is in progress. With shared, non-exclusive,
> locking read operations can run between the write transactions. There
> is a timeout (10s for Subversion) and while the whole write operation
> may take a long time the individual write transactions are generally
> shorter that the timeout.
> So from an SQLite perspective most read operations may run during a
> write operation but may block before proceeding. From a Subversion
> perspective the read operation will still fail to run if there is a
> workqueue item. So in 1.7 read operations only work if they run between
> write transactions when the workqueue is empty.

Note that with the current state we could remove the limitation of being
able to open the database while there are workqueue operations. In 1.7 we
still have workqueue operations that change the database which makes this
unsafe (like the old loggy code was), but for 1.8 these cases are

The remaining problem with enabling that, is that we should introduce a new
check point for outstanding operations. Maybe at the point where we obtain a
working copy lock?

Received on 2012-10-16 17:51:16 CEST

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