Den tis 13 juli 2021 kl 11:16 skrev Johan Corveleyn <jcor...@gmail.com>:
> On Mon, Jul 12, 2021 at 10:32 PM Daniel Sahlberg > <daniel.l.sahlb...@gmail.com> wrote: > > Den mån 12 juli 2021 kl 17:02 skrev Nathan Hartman < > hartman.nat...@gmail.com>: > >> On Mon, Jul 12, 2021 at 6:44 AM Arbeiter Ansgar < > ansgar.arbei...@boening.com> wrote: > >>> > >>> after update an repository, i normally check actual changes (with > TurtoiseMerge) so this tool and the update window are open. > >>> when i then update again (by batch file) then i very often get this > message: > >>> > >>> svn: E200030: sqlite[S10]: disk I/O error > [...] > Note that there is a config setting in the client-side "config" file > that might have some impact here (setting "exclusive locking" for the > SQLite database): > > http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking > > Also, look for "exclusive-locking" in this svnbook section: > > https://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config > > Perhaps you could test if that setting has any impact on the problem > you're seeing. > I tried to reproduce the problem with exclusive-locking = true. I get another error message in this case, E200033: [[[ C:\Devel\test>svn up svn: E200033: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server svn: E200033: sqlite[S5]: database is locked, executing statement 'PRAGMA case_sensitive_like=1;PRAGMA synchronous=OFF;PRAGMA recursive_triggers=ON;PRAGMA foreign_keys=OFF;PRAGMA locking_mode = NORMAL;PRAGMA journal_mode = TRUNCATE;' C:\Devel\test> ]]] So it seems Subversion is properly detecting that the database is already locked (as indicated by the error code 5, SQLITE_BUSY, see [1]) and give another error message. In fact, E200030 is a fallback meaning "Sqlite returned an error for which we don't have a specific Subversion errorcode" [2]. That being said and combined with the fact that the error is intermittent, makes me wonder if you might have a problem with an antivirus/security software. Maybe TortoiseSVN is updating the database, which is caught by the security software triggering a scan, then when you run `svn up` the database is still locked exclusively by the security software. When you close TortoiseMerge, there is sufficent time to complete the scan so you don't notice? (I personally hate this explaination, but I've run into strange bugs where things start to work after some whitelisting, maybe whitelist the wc.db file?). To test you could probably write a batch file along the following lines and run in a test wc. [[[ svn up echo "foo" >>test svn add test svn ci test -m test1 svn up echo "bar">>test svn ci test -m test2 svn up ]]] Kind regards, Daniel Sahlberg [1] https://sqlite.org/rescode.html#ioerr [2] https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/sqlite.c, see the macro SQLITE_ERROR_CODE
