On 2/15/06, Alexander Kitaev <alex@tmate.org> wrote:
> First:
>
> PROPFIND to get lock-token (lockdiscovery) is always sent on "svn unlock",
> independently on whether there is lock token in the working copy or not. As
> PROPFIND is sent just before "UNLOCK" I suppose that "token" passed
> toshim_svn_ra_dav_ _unlock is always NULL.
No, it's svn_client_unlock that is fetching the locks well before
ra_dav's unlock function is executed (see line 501). I'm not real
clear why we *need* to fetch the tokens from the server if we have it
already in the WC though.
> Second:
>
> Sending UNLOCK with obsolete lock-token causes server to respond with 400
> HTTP status, without any meaningful error message inside.
Are you sure about this? Here's the steps I used:
justin@machine1% svn lock htpasswd.c
'htpasswd.c' locked by user 'justin'
bob@machine2% svn lock htpasswd.c
svn: Lock request failed: 423 Locked (http://...)
bob@machine2% svn lock --force htpasswd.c
'htpasswd.c' locked by user 'bob'.
justin@machine1% svn unlock htpasswd.c
svn: Unlock request failed: 403 Forbidden (http://...)
I confirmed the network traces to ensure that the UNLOCK is being sent
correctly by the client and that it isn't getting 400 back. Client is
trunk with ra_dav and neon 0.24.7. Server is 1.3.0 with httpd 2.2.0.
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 16 18:52:09 2006