- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 23 Mar 2001 08:59:36 -0500
- To: ietf-dav-versioning@w3.org
UserA's client could do it in either order. It really doesn't matter. If the client does the LOCK first, it maximizes the chance that UserA will beat someone else who's trying to get a LOCK as well, but if someone else gets in with the LOCK of the checked out resource before you, it just means you have to wait until they are done to make your changes. As for "providing an alternative method", this assumes you have multiple workspaces or are using working resources. In these cases, you just do CHECKOUT, update, CHECKIN. No need really for a LOCK, since you have your own private workspace or working resource. Of course, you have to resolve merges in case you ended up doing this in parallel, so you avoid complexity only in cases where you don't end up in a merge situation. If you believe the "avoids complexity" sentence is misleading, let me know and I'll revise/remove it. Cheers, Geoff -----Original Message----- From: Steve K Speicher [mailto:sspeiche@us.ibm.com] Sent: Friday, March 23, 2001 7:08 AM To: ietf-dav-versioning@w3.org Subject: 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? 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? Thanks, Steve
Received on Friday, 23 March 2001 09:00:14 UTC