On 6/19/2012 3:18 PM, Achim Gratz wrote:

I suspect that svn
does not deal with the file being locked exclusively (when TortoiseSVN
accesses the database) and some call through the windows interface
blocked.

It's possible svn has a timer on the call that results in a SQL call through SQLite, and when this doesn't return as fast as svn thinks it ought to, it bombs out, complaining that there "must" be a disk I/O problem. What may actually be happening is that Windows' aggressive locking strategy has set up a deadlock between two processes.

As for why .3 and .12 behave differently, it's probably because one or more locks that used to be owned by the SQLite DLL that are now owned by the Cygwin DLL. That is, files are being accessed on the DLL's behalf by Cygwin now, rather than directly through the Windows API. Since Cygwin doubtless does file I/O differently than SQLite did, for the same basic reason that any two programmers tend to write code differently, there's a new conflict.

If this is the case, the best solution may be for TortoiseSVN to stop grabbing files for long-term exclusive use. It should only be locking the svn DB files as long as is necessary to make some change.

Note that SQLite isn't really designed for concurrent access
to the database file from a different process.

There is a paucity of truth in that statement.  See the SQLite FAQ:

        https://sqlite.org/faq.html#q5

But, there's only so much SQLite can do to cooperate with the OS's locking strategy. On POSIX systems where SQLite was born, locking is mostly advisory and cooperative, whereas Windows gives you mandatory locks by default in a lot of cases. Mandatory locks allow one process (e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to change a file, indefinitely.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply via email to