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
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking

Steve Davis <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 
---------------------------------------------------------------------------------------