1.7.1: E200033: database is locked, executing statement 'RELEASE s0'
Neil Bird
I can't find any reference online to this error code. I am trying to do
a command line 'svn cp' of one file to a new name in the same directory:
$ svn cp 3.14.7.html 3.14.8.html
svn: E200033: database is locked, executing statement 'RELEASE s0'
This with a freshly upgraded (from 1.6.17-ish, using 1.7.1 not 1.7.0) WC.
I think the issue stems from the fact that the WC is hosted on a Windows
XP box, and CIFS-mounted onto the CentOS 5 box that I am trying the
operation on (I have compiled 1.7.1 myself for CentOS 5).
The WC is otherwise behaving fine (although I vaguely recall another
Linux op. that gave me a similar lock error; I resorted to finishing on
Windows).
The same 'svn cp' works OK issued on the Windows side (using
TortoiseSVN's command-line exes).
Is there anything I can do to track this down?
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit
Daniel Shahaf
http://www.sqlite.org/atomiccommit.html
http://www.sqlite.org/lockingv3.html
states SQLite relies on POSIX advisory locks. Do those locks (fcntl() locks, if I read the source correctly) work correctly in your environment?
Neil Bird
> "database is locked" is the error SQLite would give when it tries to write to a database (.svn/wc.db) on which some other process already has a write-lock. The SQLite documentation:
No, these are not working (are they even supported by Windows? they seem
to be refs. to Samba server impls).
I can get it working by mounting my CIFS shares '-o nobrl', which despite
the scary description (about it being unsafe) would seem to be the correct
thing to do in my case.
I don't do svn ops. on the same repo. in parallel (from both machines at
the same time) anyway.
I wonder what Windows client sqlite code does over Windows shares (as
that works)?
Daniel Shahaf
On Tuesday, November 01, 2011 1:12 PM, "Neil Bird" <ne...@jibbyjobby.co.uk> wrote:
> Around about 01/11/11 12:12, Daniel Shahaf typed ...
> > "database is locked" is the error SQLite would give when it tries to write to a database (.svn/wc.db) on which some other process already has a write-lock. The SQLite documentation:
> > ... SQLite relies on POSIX advisory locks. Do those locks (fcntl() locks, if I read the source correctly) work correctly in your environment?
>
> No, these are not working (are they even supported by Windows? they seem
> to be refs. to Samba server impls).
>
> I can get it working by mounting my CIFS shares '-o nobrl', which despite
> the scary description (about it being unsafe) would seem to be the correct
> thing to do in my case.
>
> I don't do svn ops. on the same repo. in parallel (from both machines at
> the same time) anyway.
>
The issues are the same for FSFS-backed repositories and for 1.7+
working copies, since both of them use SQLite. (In 1.7 FSFS the sqlite
db's are non-authoritative.) However you mentioned CIFS-mounted working
copies, in which case the issue will be concurrent access not to the
repository but to the working copy.
Neil Bird
> ... However you mentioned CIFS-mounted working
> copies, in which case the issue will be concurrent access not to the
> repository but to the working copy.
Yeah, I said repo., but I meant WC! And I meant that I don't do more
than one thing to the WC at once (I'll either be using it from Windows or
from Linux).
Daniel Shahaf
> Around about 01/11/11 13:22, Daniel Shahaf typed ...
> >... However you mentioned CIFS-mounted working
> >copies, in which case the issue will be concurrent access not to the
> >repository but to the working copy.
>
> Yeah, I said repo., but I meant WC! And I meant that I don't do
> more than one thing to the WC at once (I'll either be using it from
> Windows or from Linux).
'svnsync --disable-locking' exists, maybe we should have a similar
option for svn then. (sqlite's source suggests that SQLite, at least
internally, does support a "Don't lock" mode.)