On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew <andrew.mar...@fisglobal.com> wrote: > Hello everyone, > > I got this error below during an svn co command. It left my workspace in a > bad state from which I had to do svn cleanup before trying again (the retry > worked): > > 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 > svn: E200042: Additional errors: > svn: E200033: sqlite[S5]: database is locked > svn: E200030: sqlite[S1]: cannot start a transaction within a transaction > svn: E200030: sqlite[S1]: cannot start a transaction within a transaction > > I think this happens when the network is flaky. This error happened on > windows but I have also seen it happen on solaris 10. Has anyone else seen > this? If it is due to network flakiness then perhaps svn should retry to work > around this transparently, and thus be more robust? Perhaps it could retry up > to 3 times with a sleep a 1 second between retries? >
Is your working copy on a network filesystem (CIFS, NFS, ...)? And are you talking about a flaky network between your machine and its networked filesystem? If so, I think there is not much we can do about it ... the filesystem you're checking out to should reliable. There is already a retry loop in some places for putting checked out files into place, to work around locks from antivirus software etc, ... (but the sqlite database itself should be reliably available). Or are you talking about flakiness of the network between your svn client and the svn server? In that case, I would not expect this kind of error. -- Johan
