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