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_at_subversion.apache.org <mailto:users_at_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_at_wandisco.com]
> Sent: 03 February 2014 15:34
> To: Steve Davis
> Cc: users_at_subversion.apache.org <mailto:users_at_subversion.apache.org>
> Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> Steve Davis <Steve.Davis_at_uk.rapp.com <mailto:Steve.Davis_at_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
> ------------------------------------------------------------------------
Received on 2014-02-03 22:51:33 CET