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

RE: Auto-version corrections

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 13 Feb 2001 18:34:07 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E225D@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
Here's some revised wording for Section 3.1.2.
Let me know if you think this is clearer.


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.

Received on Tuesday, 13 February 2001 18:25:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC