Re: DAV:lockdiscovery on a checked-out resource

> I guess all this boils down to is that UserA should
> first do a LOCK then a CHECKOUT?  ...or a CHECKOUT
> then a LOCK?

Actually, it all boils down to 'what are you trying to do'?<g>

LOCKing is designed to prevent the lost update problem.
CHECKOUT marks a version-controlled resource as mutable, and is used with
CHECKIN to create a new version.

Acquiring a LOCK on a checked-in version-controlled resource is harmless,
but versioning semantics will prevent the content of the checked-in
version-controlled resource from changing anyway.

So it depends upon your client goals -- a typical sequence for updating
content and capturing it in version history would be:
LOCK /foo
CHECKOUT /foo
GET /foo
PUT /foo
CHECKIN /foo
UNLOCK /foo

(or even GET after LOCK and before CHECKOUT).

This will guarantee that the update that you PUT is based on the content
that you GET, and that the new state is captured in the version history.
However, your initial LOCK does not prevent others from checking the
resource out 'in parallel' and creating a 'branch' (there are other
solutions for that if it is of concern).

> But section 4 "CHECKOUT Option" states: "The checkout
> option provides an alternative method that avoids the
> complexity of the locking protocol".
> How am I to interpret this sentence based on what I've
> heard in this thread?

Well, to be fair you have to take that sentence in context.
The preceding sentence talks about the undesirable proliferation of
versions that can occur if every modification is a new version, and how
LOCK can be used to bound the version creation.  The locking protocol is
only 'complex' in that it obviously requires a DAV 2 server and client
(i.e. capable of composing and parsing locking messages, considering the
If: header, remembering the lock token, etc.)  Maybe 'complexity' should be
rewritten as 'overhead' or something a little less onerous.

Tim

Received on Friday, 23 March 2001 09:47:00 UTC