W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2002

RE: Interaction of DAV:auto-version and DAV:checkout-fork

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 28 Jul 2002 08:59:39 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107A5CC3C@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

The only behavior that seems to me to be consistent with the standard
is (a), rejecting the request.  The only way that CHECKOUT can succeed
on a version that has DAV:checkout-fork as DAV:discouraged, and already
has a successor, would be if the CHECKOUT had a DAV:fork-ok argument,
and there is no way for a versioning-unaware client to add a DAV:fork-ok
argument to the auto-checkout.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Sunday, July 28, 2002 4:37 AM
To: ietf-dav-versioning@w3.org
Subject: Interaction of DAV:auto-version and DAV:checkout-fork



Hi,

consider the following scenario:

- "a" is a version controlled resource with some kind of auto-versioning
enabled, for instance DAV:checkout-unlocked-checkin,

- it's DAV:checked-in property refers to a version with a DAV:checkout-fork
property of DAV:discouraged and a non-empty DAV:successor-set property.

Non-versioning aware client attempts to modify the resource.


Possible outcomes:

a) request is rejected (409 with
DAV:checkout-of-version-with-descendant-is-discouraged),

b) request is accepted and the version history will fork.


I think both behaviours are allowed, but which one makes more sense? Right
now, I'm preferring to reject the request (standard operations on a
checked-in resource shouldn't introduce forks into the version history).

Opinions?
Received on Sunday, 28 July 2002 09:00:13 GMT

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