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:bert_at_qqmail.nl]
Sent: 02 February 2014 15:26
To: 'Ben Reser'; Steve Davis; users_at_subversion.apache.org
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
> -----Original Message-----
> From: Ben Reser [mailto:ben_at_reser.org]
> Sent: zaterdag 1 februari 2014 02:39
> To: Steve Davis; users_at_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
---------------------------------------------------------------------------------------
Received on 2014-02-03 10:46:06 CET