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
>>>
>>> when i close TurtoiseMerge (and update window) before update again, then i
>>> never noticed it.
>>> (i also checked for actually disk problems, but there are none)
>>>
>>> batch file:
>>> @echo off
>>> svn --version > nul
>>> if %ErrorLevel% gtr 0 (
>>> echo Sources can't be updated because the SVN-client not found. Please
>>> install the console tools TortoiseSVN.
>>> ) else (
>>> svn up ..\..\Axxx
>>> svn up ..\..\Cxxx
>>> svn up ..\..\Dxxx
>>> svn up ..
>>> )
>>>
>>> used versions:
>>>
>>> TortoiseMerge 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>>> libsvn_diff 1.14.1,
>>> apr 1.6.5
>>> apr-util 1.6.1
>>>
>>>
>>> TortoiseSVN 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>>> ipv6 enabled
>>> Subversion 1.14.1, -release
>>> apr 1.6.5
>>> apr-util 1.6.1
>>> serf 1.3.9
>>> OpenSSL 1.1.1i 8 Dec 2020
>>> zlib 1.2.11
>>> SQLite 3.29.0
>>>
>>> Mit freundlichen Grüßen / With kind regards
>>> i.A. Ansgar Arbeiter
>>> Graduate Engineer - Development
>
>
> I've tried to reproduce your problem but I can't. However you state that you
> get the error "very often" so maybe I'm just not lucky enough to catch it.
>
> Hello,
>>
>>
>> It sounds like one of the tools may be holding the working copy
>> database open and/or locked in some way against access by other
>> programs (e.g., a file system based locking, a SQLite EXCLUSIVE_LOCK,
>> etc).
>>
>> The error message "disk I/O error" may be misleading in this case;
>> i.e., it may not be an actual *disk* error, but rather inability to
>> open or operate on the database file for other reasons. (This error is
>> reported when the working copy's SQLite database reports SQLITE_IOERR.
>> The [S10] means the same thing as SQLITE_IOERR; it doesn't give any
>> more information. That is a generic code for a multitude of different
>> conditions.)
>>
>> It's probably just best to close the Tortoise windows when you want to
>> use the command line client; however maybe someone else on this list
>> will know a better answer. You could also try asking at the
>> TortoiseSVN mailing list (see [1] below) whether the Tortoise client
>> is expected to prevent simultaneous access by other clients, and if
>> so, whether there is a way to avoid that.
>
>
> As far as I know, TortoiseSVN never touch the working copy by it self but
> only through calling Subversion's API. (I even checked the sources but I
> couldn't "findstr" ("grep" in Unix-speech) anything related to sqlite).
>
> I seem to remember a similar question last year (?) where TortoiseSVN kept
> some resources open until the window was closed. I meant to look into it but
> never found the time. I think it was related to a temp file being held open,
> but I can't find the mail right now.
>
> The svn command line client is doing one thing at a time (per process)
> whereas in TortoiseSVN you might start one thing (for example an update),
> then with that process still "alive" start other things, either in the same
> process or as separate processes. I think (hope) that there are some
> Subversion APIs that TortoiseSVN could call to cleanup things when whatever
> it does is finished instead of relying on cleaning up things
>
> If I find time, I'll try to look at it and submit patches to TortoiseSVN. As
> Nathan already wrote, you can also ask in the TortoiseSVN mailing lists [1].
>
> [1] https://groups.google.com/g/tortoisesvn
>
> Kind regards,
> Daniel Sahlberg
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.
--
Johan
