Re: DAV:unreserved - missing precondition?

OK, that makes sense to me.

I'll make this update to both RFC-3253bis as well as JSR-147,
if there are no objections.

Cheers,
Geoff

Alison wrote on 03/22/2004 06:46:49 AM:

> The second option looks better to me, i.e.
> - disallow the checkin of an unreserved checkout if there is a 
> reserved checkout
> 
> as I think the first condition would need to be:
> 
> - disallow a reserved checkout if there is already an unreserved 
> checkout, and disallow an unreserved checkout if there is already a 
> reserved checkout.
> 
> which restricts parallel development.
> 
> Alison.

> Geoffrey M Clemm wrote:
> I believe the point of a reserved checkout was to ensure that the
> checkin would succeed.  But if we allow a reserved checkout to succeed
> when there are currently unreserved checkouts against that activity,
> if any of the unreserved checkouts are checked in, the subsequent
> checkin of the reserved checkout will fail.
> 
> So doesn't that imply we should either:
> - disallow a reserved checkout if there is already an unreserved 
checkout
> or
> - disallow the checkin of an unreserved checkout if there is a reserved 
> checkout
> ?
> 
> Cheers,
> Geoff
> 
> Alison wrote on 03/18/2004 08:08:27 AM:
> 
> 
> The 13.3.1 description of DAV:unreserved is more restrictive  than 
> DAV:one-checkout-per-activity-per-history enforces. The description 
> only allows for one checked-out resource for the activity, if that 
> checked-out resource has DAV:unreserved false. The precondition 
> however allows for multiple checked-out resources for the activity, 
> where at most one of these has a DAV:unreserved property of false. 
> 
> Given existing implementations of 3253 which may only enforce the 
> precondition rather than the description, I would suggest that the 
> description of DAV:unreserved is lined up with the precondition. 
> That is, at most one reserved (DAV:unreserved false) checked out 
> resource for an activity, but any number of unreserved (DAV:
> unreserved true) checked out resources for the same activity.
> 
> Geoffrey M Clemm wrote:
> Either interpretation is OK with me.  Do you (or anyone else) want
> this to be added?
> 
> Alison wrote on 03/12/2004 01:04:43 PM:
> 
> Section 13.3.1 of the spec says:
> 
> 
> 13.3.1 DAV:unreserved
> This property of a checked-out resource indicates whether the 
> DAV:activity-set of another checked-out resource associated with the 
> version history of this version-controlled resource can have an 
> activity that is in the DAV:activity-set property of this checked-out 
> resource.
> 
> The activity feature adds a checkout precondition:
> 
> 
> (DAV:one-checkout-per-activity-per-history): If there is a request 
> activity set, unless DAV:unreserved is specified, another checkout 
> from a version of that version history MUST NOT select an activity in 
> that activity set.
> 
> Should this precondition also cover the case where the checkout request 
> includes an activity and specifies DAV:unreserved, but the checkout 
> should fail because a checked-out resource already exists, with 
> DAV:unreserved false, and a DAV:activity-set value that contains the 
> checkout request activity?
> 
> 
> 
> 
> 
>

Received on Monday, 22 March 2004 07:10:02 UTC