Hello Justin,
Here what I have at the working copy:
C:\test\svn\wc\lock\trunk>svn st -vu .
T 2 2 first file.txt
1 1 first .
Status against revision: 2
file.txt was first locked by user "first" and then lock was stolen by the
user "second".
Lock-token in the working copy is:
lock-token="opaquelocktoken:1aec487f-520d-0410-9ab9-d21134449303"
Then I'm trying to do unlock (with subversion 1.3.0 command line client) and
get the following:
Full ethereal log: http://tmate.org/svn/svn-unlock.pcap
====================================
PROPFIND /svn/repos/lock/trunk/file.txt HTTP/1.0
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/vcc/default HTTP/1.0
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/bln/2 HTTP/1.0
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/trunk/file.txt HTTP/1.0
<?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"><prop>
<lockdiscovery xmlns="DAV:"/> </prop></propfind>
HTTP/1.1 207 Multi-Status (text/xml)
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:">
<D:response>
<D:href>/svn/repos/lock/trunk/file.txt</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery><D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:47c74381-520d-0410-8f02-e6b196271972</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.0
Host: 80.188.80.120
User-Agent: SVN/1.3.0 (r17949) neon/0.25.4
Lock-Token: <opaquelocktoken:47c74381-520d-0410-8f02-e6b196271972>
Via: 1.1 localhost:3128 (squid/2.5.STABLE12-NT)
X-Forwarded-For: 127.0.0.1
Cache-Control: max-age=259200
Connection: keep-alive
HTTP/1.1 401 Authorization Required (text/html)
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.0
HTTP/1.1 403 Forbidden (text/html)
===================================
Please note the following:
1. Lock token sent differs from the one stored in the working copy.
2. Server sends 403 HTTP response only because credentials of the user are
different from those of the lock owner, and server doesn't report that the
lock is stolen.
When I'm using JavaSVN, that uses lock-token from the working copy, I get
the following log:
Full ethereal log: http://tmate.org/svn/javasvn-unlock.pcap
===================================
PROPFIND /svn/repos/lock/trunk/file.txt HTTP/1.1
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/vcc/default HTTP/1.1
HTTP/1.1 207 Multi-Status (text/xml)
PROPFIND /svn/repos/lock/!svn/bln/2 HTTP/1.1
HTTP/1.1 207 Multi-Status (text/xml)
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.1
HTTP/1.1 401 Authorization Required (text/html)
UNLOCK /svn/repos/lock/trunk/file.txt HTTP/1.1
Host: 80.188.80.120:80
User-Agent: JavaSVN (http://tmate.org/svn/)
Keep-Alive: Connection: TE, Keep-Alive
TE: trailers Authorization:
Basic Zmlyc3Q6Zmlyc3Q=
Content-Length: 0
Accept-Encoding: gzip
Content-Type: text/xml; charset="utf-8"
Lock-Token: <opaquelocktoken:1aec487f-520d-0410-9ab9-d21134449303>
HTTP/1.1 400 Bad Request (text/html)
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
===================================
Please, note:
1. Lock token from the working copy is used.
2. Server response doesn't contain error message.
3. Apache error log contains the following line:
(2)No such file or directory: The locktoken specified in the "Lock-Token:"
header did not specify one of this resource's locktoken(s). [400, #0]
The problem that affects end-user is that in both cases error message is not
relevant and doesn't explain why the file cannot be unlocked.
Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/
> -----Original Message-----
> From: justin.erenkrantz@gmail.com
> [mailto:justin.erenkrantz@gmail.com] On Behalf Of Justin Erenkrantz
> Sent: Thursday, February 16, 2006 18:39
> To: alex@tmate.org
> Cc: SVN Dev
> Subject: Re: DAV unlock problem.
>
> 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 Tue Feb 21 21:09:57 2006