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

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:[email protected]]
Sent: Sunday, July 28, 2002 4:37 AM
To: [email protected]
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?