Hi Bert - Firstly - is this content posting into a forum somewhere? It might be easier for me to view it there than in email each time...
Answering your suggestions are easy; I am creating the repository completely manually using svnadmin create f:\svn_repository\Testrepo so, there is no part of bitnami touching this during the creation - just standard svn itself. When I look at the hooks folder for the repository, all of the items in there are the standard .tmpl (ie template) files, which as I understand it have absolutely no effect on the system; if they were modified and changed to .bat files then they would apply. So I don't see how hook files can be playing any part in this. But thanks for the feedback nonetheless; it's all helpful in ruling out what could be occurring here Kind Regards - Steve -----Original Message----- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: 02 February 2014 15:26 To: 'Ben Reser'; Steve Davis; users@subversion.apache.org Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking > -----Original Message----- > From: Ben Reser [mailto:b...@reser.org] > Sent: zaterdag 1 februari 2014 02: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? And can you check what repository hooks are installed into your repository by the Bitnami framework? You can get into this exact problem if you have a pre-lock script that produces some whitespace only output on stdout. The output of this hook is used as lock token. (See http://subversion.apache.org/docs/release-notes/1.6.html#hook-changes) But in this case the surrounding whitespace is filtered and an empty token is exactly what remains. Bert 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 ---------------------------------------------------------------------------------------
