Re: DAV:unreserved - missing precondition?

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