W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Auto-version corrections

From: Greg Stein <gstein@lyra.org>
Date: Tue, 13 Feb 2001 18:29:25 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010213182924.I24939@lyra.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT