  Re: DAV:lockdiscovery on a checked-out resource  From:
<Tim_Ellison@uk.ibm.com> Date: Fri, 23 Mar 2001 13:38:30 +0000
To: ietf-dav-versioning@w3.org Message-ID:
<80256A18.004AF295.00@d06mta07.portsmouth.uk.ibm.com>  > 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.  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 GET /foo PUT /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 versi