- From: Greg Stein <gstein@lyra.org>
- Date: Tue, 13 Feb 2001 18:29:25 -0800
- To: ietf-dav-versioning@w3.org
Looks very good to me. Cheers, -g On Tue, Feb 13, 2001 at 06:34:07PM -0500, Clemm, Geoff wrote: > Here's some revised wording for Section 3.1.2. > Let me know if you think this is clearer. > > Cheers, > Geoff > > 3.1.2 Modifying a Version-Controlled Resource > > In order to use methods like PUT and PROPPATCH to directly modify the > content or dead properties of a version-controlled resource, the > version-controlled resource must first be checked out. When the checked-out > resource is checked in, a new version is created in the version history of > that version-controlled resource. The version that was checked out is > remembered as the predecessor of the new version. > > The DAV:auto-version property (see Section 3.3.2) of a checked-in > version-controlled resource determines how it responds to a method that > attempts to modify its content or dead properties. The four possible > responses are: > > - Fail the request. The resource requires an explicit CHECKOUT request for > it to be modified (see Sections 5). > > - Fail the request unless the resource is write-locked. If it is > write-locked, automatically checkout the resource and perform the > modification. The resource remains checked-out until the write-lock is > removed (either explicitly through a subsequent UNLOCK request or implicitly > through a time-out of the write-lock). This avoids the proliferation of > versions that can result if every modification creates a new version. > > - Automatically checkout the resource, perform the modification, and then if > the resource is not write-locked, automatically checkin the resource. If > the resource is write-locked, it remains checked-out until the write-lock is > removed. This helps a locking client avoid the proliferation of versions, > while still allowing a non-locking client to update the resource. > > - Automatically checkout the resource, perform the modification, and > automatically checkin the resource. This ensures that every state of the > resource is tracked by the server, but can result in an excessive number of > versions being created. > > ... -- Greg Stein, http://www.lyra.org/
Received on Tuesday, 13 February 2001 21:27:21 UTC