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
