Justin Erenkrantz wrote:
> --On Thursday, October 14, 2004 9:43 AM +0200 Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>> I'd call a client that requires a LOCK before GET a poor
>> implementation (if
>> it only wants to read the file). A LOCK doesn't guarantee you the
>> "youngest"
>> revision any more than GET. All it guarantees is that nobody changes the
>> resource between the LOCK and the GET (so you win exactly nothing
>> compared
>> to doing the GET right away).
>
>
> No. The initial argument was that 'svn lock' implicitly does 'svn
> update.' Therefore, if we go down this path (which I don't want us to,
> FWIW: they should be separate operations), I believe the ordering is
> critical because 'svn lock' is implying that the user has the absolute
> latest version before they do a write operation locally. If you did a
> GET and then a LOCK, it's feasible that you don't have the latest
> version locally and the 'svn lock' behavior doesn't match the
> expectation. -- justin
OK, confusion. I was talking about WebDAV clients in general: doing a
LOCK just to make sure you have the 'latest' version doesn't make sense
unless you are really going to lock the resource. From RFC2518's point
of view, GET always gets you the latest content anyway. The best way to
avoid overlapping updates (PUTting back something that somebody else has
modified since) is to add a check on the entity tag using the "If-Match"
request header.
So yes, if you actually do want to LOCK the resource, LOCK it first,
*then* get the content.
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 09:07:14 2004