Re: Auto-version corrections

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 :-)

Cheers,
-g

> 
> 
> 
> 
> 
> "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