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

RE: auto-version

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 11 Jan 2001 09:56:30 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B101A62B9C@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
Good points.  I'll fix that up.

While I'm in there, Jim Amsden asked if we could add a
value to DAV:auto-version that says "only auto version
while locked" (i.e. this would say to auto-checkout if
the checked-in vcr is write-locked, but just fail the
update if it is not write-locked).

I think this is a decision more likely to made by the
server (i.e. does it have an efficient delta scheme for
that resource type), but I'd be happy to add this if 
folks think it's a good idea.  Any preference?

This brings to mind another point ... currently we have
a couple of properties that take string values of "true"
and "false".  It occurs to me that it would be cleaner to
have elements called "DAV:true" and "DAV:false".  Any
objections to this change?


-----Original Message-----
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
Sent: Thursday, January 11, 2001 9:21 AM
To: ietf-dav-versioning@w3.org
Subject: DAV:auto-version

From versioning-11

2.2.5 DAV:auto-version

When the DAV:auto-version property of a checked-out version-controlled
resource is set, a modification request (such as PUT/PROPPATCH) is
automatically preceded by a checkout operation.

(1) Oops, I think that should be referring to a checked-in VCR.

(2) If I was going to be pedantic I would say that the property should be
set, and its value should be 'true' .

(3) We seem to have lost the description of 'doing no harm' during
modification failures (words to te effect that if the PUT fails the server
should be left as though non of the CHECKOUT-PUT-CHECKIN sequence


Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK.
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452
Received on Thursday, 11 January 2001 09:57:25 UTC

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