Hi - I have been trying to pin down the cause of an issue my users are seeing when using SVN. It's actually a Windows Server 2008 R2 (64 bit) Bitnami-Redmine stack of SVN, but I've tried to scrape it back to the most basic levels during debugging, to hopefully omit any Bitnami-related issues.
I have seen this occur when the underlying SVN install is 1.8.3 and 1.8.4 I have performed the following actions (on the server itself, sing the bitnami cmd prompt to ensure all environment variables for SVN should be as expected) :: Create a new repository. No options or extras - no hooks. svnadmin create f:\svn_repository\Testrepo :: Check the empty repo out to my local disk (on the SVN Server) - obviously I've masked the real address here svn co https://xxxxxxxxxxxxxx.com/svn/Testrepo c:\dev\Testrepo :: created a simple text file manually under windows - NewDoc.txt with a few bytes of text in it so it's not empty :: Made SVN aware of the file by adding it svn add c:\dev\Testrepo\NewDoc.txt :: Committed the file into the repository svn ci c:\dev\Testrepo -m "test commit" :: Attempted to lock the working file svn lock c:\dev\Testrepo\NewDoc.txt Response: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL svn: E200035: Additional errors: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL I've been digging around on this for a while - seen one or two examples of people seeing this, but not seen any solutions as-of-yet. I couldn't find any trace of a bug raised either (Hopefully I've not missed one!) I've first seen this in a Bitnami 2.3.2.1 install, and to try to make sure it's not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 install: Same result. I have tried a totally standalone collabnet svn server install of 1.8.5 on a separate machine, and the locks on that are working. I then put 1.8.5 onto the server where we're seeing the problem and once again the same problem occurred. So this seems to be an issue occurring as a result of the configuration setup we have on that server. We do make use of an access file on that server, so my next test was to disable the access file setup and retry. This worked exactly as expected (by using a checkout using the local file system), responding that the file had been locked So, it would seem that this issue is related to the use of the following httpd.conf settings: LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.s And/or serving the files over https And the related settings pointing to the relevant access authority file. Can anyone advise or assist with this? Has anyone else seen this issue? I'm starting to run out of ideas of how to further pinpoint this at the moment... Many thanks for any advice or assistance! Regards - Steve This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personnel and agents. A division of Rapp Limited. Registered Office: 1 Riverside, Manbre Road, London W6 9WA Registered in England no: 1581935 --------------------------------------------------------------------------------------- This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.co.uk ---------------------------------------------------------------------------------------
