On Fri, Jul 6, 2012 at 2:20 PM, Simon Large <simon.tortoisesvn_at_gmail.com> wrote:
> On 6 July 2012 09:04, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
>> On Fri, Jul 6, 2012 at 12:58 AM, Neels J Hofmeyr <neels_at_elego.de> wrote:
>>> Today Random Person on #svn reported a problem and later its apparent
>>> solution, and it struck me as rather peculiar:
>>> <yates`> when trying to do an svn cleanup, i get a strange message:
>>> svn: E200030: disk I/O error, executing statement 'COMMIT TRANSACTION;'
>> I suspect a reader / writer locking issue with Sqlite.
>> The I/O error as such might be related to the win7 /
>> cygwin combination requiring more retries or such.
>>> this is under win7 using the cygwin svn client
>>> and also tortoisesvn is installed
>>> <yates`> neels: i found the issue
>>> strangely, there is an interaction between tortoisesvn and the cli svn
>>> you must disable tortoisesvn's icon caching, then the problem goes away.
>> I.e. they disabled the background process that will
>> open the working copy soon after the OS detected
>> some file change. The scan itself may take a very
>> long time. Depending on OS and wc details, the db
>> may get opened at some very inconvenient time
>> while the commit is still in progress / in some critical
>>> "I've confirmed what others have stated that it's only a problem with
>>> v188.8.131.52 and NOT a problem with v3.7.3."
>>> Hmm, disable icon caching to not break wc-ng? Why!?
>> I think to remember that access to WCNG is much
>> more exclusive than it used to be in 1.6. But I don't
>> know whether that is actually true not the details.
> In our FAQ we advise against using TortoiseSVN with CygWin because
> Subversion was never designed to share a working copy between Windows
> and *nix clients. I thought this was in the SVN FAQ too, but can't
> find it right now.
Ok, but I suppose that's mainly because of eol-style=native issues:
your cygwin client may have a different idea about what the native
eol-style is ... I don't think locking of the working copy (or working
copy database) has been considered when this faq entry was written ...
BTW: I have also recently recommended my users to make sure icon
caching is disabled if they have TSVN installed. My users are mainly
using IntelliJ IDEA with svnkit, and they also sometimes experience an
E200030 error ("svn: E200030: BUSY"  in this case). Though I'm
really shooting in the dark with this recommendation: I don't know if
TSVNCache is involved at all (it's just a guess: trying to reduce the
components on the system that may potentially be messing with the
working copy at the same time) -- it may just as well be an internal
svnkit or IntelliJ IDEA problem (some kind of multithreaded access
inside IDEA that's not properly synchronized ... I don't know at this
Anyway, just wanted to point that out. I have actually no idea what
TSVNCache does with the working copy: does it query the database, what
kind of locking effect it has, what if querying the wc.db takes a long
time ... ? Can TSVNCache block out other clients from accessing or
modifying the working copy?
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-07-06 15:16:58 CEST