[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking UI comments

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2004-10-15 09:06:38 CEST

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.


<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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.