Hi Ben - To try to answer as many of the questions you raised as possible:
In the httpd error_log I'm seeing this each time I attempt to lock a file and fail: [Mon Feb 03 10:58:52.092999 2014] [dav:error] [pid 2776:tid 1160] [client xx.xx.xx.xx:xxxxx] Tried to attach multiple locks to a resource. [400, #405] This has lead me off on another set of googling to try and pin this down. It would seem again that a few people have seen the same or very similar, specifically in the windows environment. But I still see no sign of a resolution forthcomng (yet) Eg: http://community.bitnami.com/t/cannot-svn-lock-files-with-bitnami-trac-1-0-1-client-400-bad-request-server-tried-to-attach-multiple-locks-to-a-resource/14779/21 Again, from the httpd error log I see the apache version details as follows: [Mon Feb 03 10:26:21.216999 2014] [mpm_winnt:notice] [pid 4932:tid 384] AH00455: Apache/2.4.7 (Win32) SVN/1.8.4 OpenSSL/0.9.8y PHP/5.4.0 configured -- resuming normal operations During further testing today, I have tried to simplify the scenario by 1) Eliminating the secure (https) connection redirection that was in place 2) Replacing the complex access file config we normally have in place with the more straightforward (I was say simple as I'm sure it's not under the covers!) AuthBasicProvider file. You have to have some sort of authentication in place otherwise the lock fails (which is logical) So, I now have a scenario which should be far more easy to recreate on another system and (hopefully) easier to debug. The process I used is as follows: 1) Install Bitnami Redmine stack 2.4.2 from https://bitnami.com/stack/redmine 2) Modify (installdir)\apache2\conf\bitnami\bitnami.conf, adding the following line at the end of the file: include "F:/BitNami/redmine-2.4.2-0/apache2/conf/bitnami/rapp.conf" (Modify the base install dir as needed) 3) Add the attached rapp.conf file into the (installdir)\apache2\conf\bitnami directory (This contains the relevant DAV access settings) 4) Add a user to the new password file htpasswd -c c:\svn_admin\passwords.txt steve 5) Restart apache using either the standard windows service or the bitnami config tool (Start /Programs / Bitnami Redmine Stack / Redmine Manager Tool) Then follow the sequence (as documented before, but using http instead of https) :: 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 http://xxxxxxxxxxxxxx.com/svn/Testrepo c:\dev\Testrepo :: (create 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 Additional content in httpd error.log: [Mon Feb 03 12:30:13.322999 2014] [dav:error] [pid 4968:tid 1148] [client xxx.xxx.xxx.xxx:xxxxx] Tried to attach multiple locks to a resource. [400, #405] I've also attached both the httpd.conf and the bitnami.conf files to help with debugging. Pretty much everything in the conf files is 'as installed in the bitnami stack' with the only modifications made being those mentioned above - basically implementing DAV and basic security to permit the testing to be done (given that using file:/// type access does not recreate the issue). I will talk to my network people to see if we can track down the net traffic and post that too. Any further feedback very much appreciated. Thanks - Steve -----Original Message----- From: Ben Reser [mailto:b...@reser.org] Sent: 01 February 2014 01:39 To: Steve Davis; users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking On 1/31/14, 1:54 PM, Steve Davis wrote: > :: 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 What if anything is in the httpd error_log? Can you capture the network traffic between the server and the client and post it (removing Authentication headers) for the LOCK request? > 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'm not familiar with Bitnami Redmine, can you tell us what version of httpd you have with it? > 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 Doubtful. > And the related settings pointing to the relevant access authority file. This is more likely. Can you post your configuration? 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 ---------------------------------------------------------------------------------------
rapp.conf
Description: rapp.conf
bitnami.conf
Description: bitnami.conf
httpd.conf
Description: httpd.conf
