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: Wed, 14 Feb 2001 13:47:15 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010214134715.C27443@lyra.org>
On Wed, Feb 14, 2001 at 10:18:10AM -0500, Jim Amsden wrote:
> Consider removing item 3. It seems gratuitous. If you have a locking

Absolutely not. That is one of the best options. It allows Word 2000 to
create a single version (by waiting for its UNLOCK), and it allows somebody
using PUT (no LOCK/UNLOCK) to create a version. It is the right blend.

> You could also consider removing the first item. A core versioning server 
> that supports the checkout option should still support locking semantics.

Says who? That is a silly statement. Subversion isn't going to support
locking semantics at all. You'll get a 405 if you send a LOCK or UNLOCK.
Versioning servers don't need locking semantics -- they allow multiple
people to work on resources simultaneously. Think, "parallel development".
That is the antithesis of locks.

> Doing these two things makes DAV:auto-version a Boolean again.

Sorry. All four stay :-)


> "Clemm, Geoff" <gclemm@rational.com>
> Sent by: ietf-dav-versioning-request@w3.org
> 02/13/2001 06:34 PM
>         To:     ietf-dav-versioning@w3.org
>         cc: 
>         Subject:        RE: Auto-version corrections
> 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 Wednesday, 14 February 2001 16:46:45 UTC

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