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 <mailto: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.mar...@wandisco.com]
Sent: 03 February 2014 15:34
To: Steve Davis
Cc: users@subversion.apache.org <mailto:users@subversion.apache.org>
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Steve Davis <steve.da...@uk.rapp.com <mailto:steve.da...@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
------------------------------------------------------------------------
