You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Davis <St...@uk.rapp.com> on 2014/01/31 22:54:33 UTC
Possible bug in SVN 1.8.3 and 1.8.4 - file locking
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
---------------------------------------------------------------------------------------
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Steve Davis <St...@uk.rapp.com>.
Great, Thanks. My expectation is that it will all work fine... until you get to file locking - which will fail.
-----Original Message-----
From: Alagazam.net Subversion [mailto:svn@alagazam.net]
Sent: 03 February 2014 21:51
To: Steve Davis
Cc: users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Hi everyone.
I got curious to see if they are using my VC6 build of Subversio a.k.a.
Win32SVN. And my suspision it true, it's the Win32SVN 1.8.4 build for Apache 2.4.x that's is included in the Bitnami Redmine Windows installer.
Building Win32SVN and testing is done against a httpd built at the same time (or sometimes a previous build) with the same compiler VC6.
I haven't tested Win32SVN with httpd built using more modern VC++.
It seems like Bitnami's httpd it built with VS2010 (at least as Dependency Walker shows).
If time permit I can try to run the svn testsuite with these installation.
Best regards
David a.k.a. Alagazam
Maintainer of Win32SVN
On 2014-02-03 17:31, Steve Davis wrote:
> Ah - with a bit of digging around the binary libraries, I can see that
> it looks like subversion was still built using vc6, and apache using a
> mix of 2008 and/or 2010.
>
> This being the case, I'd say that this is a prime candidate for what's
> causing the problem (based upon the comments in the second link)...
>
> So it's not a problem with Redmine or with apache - but it >is< a
> problem when the binaries used aren't built using the same version of
> compiler (this is all theory at the moment of course)
>
> -----Original Message-----
> From: Steve Davis
> Sent: 03 February 2014 15:35
> To: 'Philip Martin'
> Cc: users@subversion.apache.org <ma...@subversion.apache.org>
> Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> All of the Apache and Subversion binaries came from the Bitnami
> download. I could ask their support people exactly what compiler was
> used if you think that would help? Anything else I should be asking
> them at the same time?
>
> Thanks for your time on this
>
> Regards - Steve
>
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: 03 February 2014 15:34
> To: Steve Davis
> Cc: users@subversion.apache.org <ma...@subversion.apache.org>
> Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> Steve Davis <Steve.Davis@uk.rapp.com ><ma...@uk.rapp.com>>
> writes:
>
> > 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 can generate this error with the 1.8 client by patching mod_dav_svn
> to return 400:
>
> Index: sw/subversion/src/subversion/mod_dav_svn/lock.c
> ===================================================================
> --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833)
> +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy)
> @@ -670,7 +670,7 @@
> DAV_ERR_LOCK_SAVE_LOCK,
> "Path is not accessible.");
>
> - if (lock->next)
> + /*if (lock->next)*/
> return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST,
> DAV_ERR_LOCK_SAVE_LOCK, "Tried to attach multiple locks to a
> resource.");
>
> A trunk client gives a better error:
>
> svn: warning: W160040: No lock on path 'f' (400 Bad Request)
>
> The question remains why are you getting a 400 Bad Request from the
> server. As far as I am aware this has only ever been observed by
> people using Windows and I think it could be an incompatibility
> between the way Apache and Subversion are built. In this discussion:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessag
> eId=894838
>
>
> a patch/rebuild is reported to fix the problem but the person
> producing the patch realises that the patch does nothing. Therefore
> what solved the problem was the rebuild, not the patch. In the same discussion:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessag
> eId=905320
>
>
> somebody else reports a similar incompatibility which was solved by
> using different binaries.
>
> Do you know how your Apache and Subversion binaries were produced?
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
>
> 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
> ----------------------------------------------------------------------
> --
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
---------------------------------------------------------------------------------------
Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by "Alagazam.net Subversion" <sv...@alagazam.net>.
Hi everyone.
I got curious to see if they are using my VC6 build of Subversio a.k.a.
Win32SVN. And my suspision it true, it's the Win32SVN 1.8.4 build for
Apache 2.4.x that's is included in the Bitnami Redmine Windows installer.
Building Win32SVN and testing is done against a httpd built at the same
time (or sometimes a previous build) with the same compiler VC6.
I haven't tested Win32SVN with httpd built using more modern VC++.
It seems like Bitnami's httpd it built with VS2010 (at least as
Dependency Walker shows).
If time permit I can try to run the svn testsuite with these installation.
Best regards
David a.k.a. Alagazam
Maintainer of Win32SVN
On 2014-02-03 17:31, Steve Davis wrote:
> Ah - with a bit of digging around the binary libraries, I can see that
> it looks like subversion was still built using vc6, and apache using a
> mix of 2008 and/or 2010.
>
> This being the case, I'd say that this is a prime candidate for what's
> causing the problem (based upon the comments in the second link)...
>
> So it's not a problem with Redmine or with apache - but it >is< a
> problem when the binaries used aren't built using the same version of
> compiler (this is all theory at the moment of course)
>
> -----Original Message-----
> From: Steve Davis
> Sent: 03 February 2014 15:35
> To: 'Philip Martin'
> Cc: users@subversion.apache.org <ma...@subversion.apache.org>
> Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> All of the Apache and Subversion binaries came from the Bitnami
> download. I could ask their support people exactly what compiler was
> used if you think that would help? Anything else I should be asking them
> at the same time?
>
> Thanks for your time on this
>
> Regards - Steve
>
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: 03 February 2014 15:34
> To: Steve Davis
> Cc: users@subversion.apache.org <ma...@subversion.apache.org>
> Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> Steve Davis <Steve.Davis@uk.rapp.com <ma...@uk.rapp.com>>
> writes:
>
> > 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 can generate this error with the 1.8 client by patching mod_dav_svn to
> return 400:
>
> Index: sw/subversion/src/subversion/mod_dav_svn/lock.c
> ===================================================================
> --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833)
> +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy)
> @@ -670,7 +670,7 @@
> DAV_ERR_LOCK_SAVE_LOCK,
> "Path is not accessible.");
>
> - if (lock->next)
> + /*if (lock->next)*/
> return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST,
> DAV_ERR_LOCK_SAVE_LOCK,
> "Tried to attach multiple locks to a resource.");
>
> A trunk client gives a better error:
>
> svn: warning: W160040: No lock on path 'f' (400 Bad Request)
>
> The question remains why are you getting a 400 Bad Request from the
> server. As far as I am aware this has only ever been observed by people
> using Windows and I think it could be an incompatibility between the way
> Apache and Subversion are built. In this discussion:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838
>
>
> a patch/rebuild is reported to fix the problem but the person producing
> the patch realises that the patch does nothing. Therefore what solved
> the problem was the rebuild, not the patch. In the same discussion:
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320
>
>
> somebody else reports a similar incompatibility which was solved by
> using different binaries.
>
> Do you know how your Apache and Subversion binaries were produced?
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
>
> 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
> ------------------------------------------------------------------------
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Steve Davis <St...@uk.rapp.com>.
Ah - with a bit of digging around the binary libraries, I can see that it looks like subversion was still built using vc6, and apache using a mix of 2008 and/or 2010.
This being the case, I'd say that this is a prime candidate for what's causing the problem (based upon the comments in the second link)...
So it's not a problem with Redmine or with apache - but it >is< a problem when the binaries used aren't built using the same version of compiler (this is all theory at the moment of course)
-----Original Message-----
From: Steve Davis
Sent: 03 February 2014 15:35
To: 'Philip Martin'
Cc: users@subversion.apache.org
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
All of the Apache and Subversion binaries came from the Bitnami download. I could ask their support people exactly what compiler was used if you think that would help? Anything else I should be asking them at the same time?
Thanks for your time on this
Regards - Steve
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: 03 February 2014 15:34
To: Steve Davis
Cc: users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Steve Davis <St...@uk.rapp.com> writes:
> 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 can generate this error with the 1.8 client by patching mod_dav_svn to return 400:
Index: sw/subversion/src/subversion/mod_dav_svn/lock.c
===================================================================
--- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833)
+++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy)
@@ -670,7 +670,7 @@
DAV_ERR_LOCK_SAVE_LOCK,
"Path is not accessible.");
- if (lock->next)
+ /*if (lock->next)*/
return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST,
DAV_ERR_LOCK_SAVE_LOCK,
"Tried to attach multiple locks to a resource.");
A trunk client gives a better error:
svn: warning: W160040: No lock on path 'f' (400 Bad Request)
The question remains why are you getting a 400 Bad Request from the server. As far as I am aware this has only ever been observed by people using Windows and I think it could be an incompatibility between the way Apache and Subversion are built. In this discussion:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838
a patch/rebuild is reported to fix the problem but the person producing the patch realises that the patch does nothing. Therefore what solved the problem was the rebuild, not the patch. In the same discussion:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320
somebody else reports a similar incompatibility which was solved by using different binaries.
Do you know how your Apache and Subversion binaries were produced?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
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
---------------------------------------------------------------------------------------
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Steve Davis <St...@uk.rapp.com>.
All of the Apache and Subversion binaries came from the Bitnami download. I could ask their support people exactly what compiler was used if you think that would help? Anything else I should be asking them at the same time?
Thanks for your time on this
Regards - Steve
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: 03 February 2014 15:34
To: Steve Davis
Cc: users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Steve Davis <St...@uk.rapp.com> writes:
> 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 can generate this error with the 1.8 client by patching mod_dav_svn to return 400:
Index: sw/subversion/src/subversion/mod_dav_svn/lock.c
===================================================================
--- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833)
+++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy)
@@ -670,7 +670,7 @@
DAV_ERR_LOCK_SAVE_LOCK,
"Path is not accessible.");
- if (lock->next)
+ /*if (lock->next)*/
return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST,
DAV_ERR_LOCK_SAVE_LOCK,
"Tried to attach multiple locks to a resource.");
A trunk client gives a better error:
svn: warning: W160040: No lock on path 'f' (400 Bad Request)
The question remains why are you getting a 400 Bad Request from the server. As far as I am aware this has only ever been observed by people using Windows and I think it could be an incompatibility between the way Apache and Subversion are built. In this discussion:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838
a patch/rebuild is reported to fix the problem but the person producing the patch realises that the patch does nothing. Therefore what solved the problem was the rebuild, not the patch. In the same discussion:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320
somebody else reports a similar incompatibility which was solved by using different binaries.
Do you know how your Apache and Subversion binaries were produced?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
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
---------------------------------------------------------------------------------------
Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Philip Martin <ph...@wandisco.com>.
Steve Davis <St...@uk.rapp.com> writes:
> 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 can generate this error with the 1.8 client by patching mod_dav_svn to
return 400:
Index: sw/subversion/src/subversion/mod_dav_svn/lock.c
===================================================================
--- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833)
+++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy)
@@ -670,7 +670,7 @@
DAV_ERR_LOCK_SAVE_LOCK,
"Path is not accessible.");
- if (lock->next)
+ /*if (lock->next)*/
return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST,
DAV_ERR_LOCK_SAVE_LOCK,
"Tried to attach multiple locks to a resource.");
A trunk client gives a better error:
svn: warning: W160040: No lock on path 'f' (400 Bad Request)
The question remains why are you getting a 400 Bad Request from the
server. As far as I am aware this has only ever been observed by people
using Windows and I think it could be an incompatibility between the way
Apache and Subversion are built. In this discussion:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838
a patch/rebuild is reported to fix the problem but the person producing
the patch realises that the patch does nothing. Therefore what solved
the problem was the rebuild, not the patch. In the same discussion:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320
somebody else reports a similar incompatibility which was solved by
using different binaries.
Do you know how your Apache and Subversion binaries were produced?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Steve Davis <St...@uk.rapp.com>.
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:ben@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
---------------------------------------------------------------------------------------
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Steve Davis <St...@uk.rapp.com>.
Hi Ben -
Hopefully this is the information (attached) you wanted to see in respect of the network traffic (I've blanked out urls, but rest assured they're there in the originals!)
If not, please do let me know. (I'm no networking specialist I'm afraid - and a beginner with Wireshark therefore)
If you need any more information at all, please do let me know
Thanks again for your input
Kind Regards - Steve
-----Original Message-----
From: Ben Reser [mailto:ben@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
---------------------------------------------------------------------------------------
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Steve Davis <St...@uk.rapp.com>.
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@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:ben@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
---------------------------------------------------------------------------------------
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ben Reser [mailto:ben@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
Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Posted by Ben Reser <be...@reser.org>.
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?