RE: UPDATE semantics for checked-out resources

OK, unless anyone wants to suggest otherwise, I'll just
consider the issue closed, and not bother adding it to
the Errata.

Cheers,
Geoff

(For some reason, I'm getting my posts back as HTML, which
is really strange since I send them out in plain text ...)

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Friday, September 27, 2002 10:26 AM
To: Clemm, Geoff
Cc: ietf-dav-versioning@w3.org
Subject: Re: UPDATE semantics for checked-out resources



Am Freitag, 27.09.02, um 16:13 Uhr (Europe/Berlin) schrieb Clemm, Geoff:

> Apologies, I misread the original message (i.e. the issue is the
> checkout of a member of the collection, not a checkout of the
> collection).
>
> This is just one way in which you can delete a checked-out VCR, and
> currently, deleting a checked-out VCR is allowed by the protocol.

I see where this is going...

I think DELETE on a checked-out VCR must be ok. However if I UPDATE
a collection and someone else checked out the contained VCR and
that VCR is silently deleted, all his/her changes are lost.

Which can happen anyway, unless she/he locks the VCR.

Therefore I change my mind and from now on to forver say that
explicit and implicit DELETE on checked-out resources are "OK".

//Stefan

> Stefan: Were you suggesting that it be disallowed just in this case,
> or disallowed in general (e.g. add it as a precondition to the DELETE
> method).
>
> For now, I'll just add this to the Errata document as an open issue,
> since disallowing deletion of a checked-out VCR would be a change
> to the protocol semantics.
>
> So, to get some initial feedback, who thinks we should disallow the
> deletion of a checked-out VCR?
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Manfred Baedke [mailto:manfred.baedke@greenbytes.de]
> Sent: Friday, September 27, 2002 9:21 AM
> To: Clemm, Geoff; ietf-dav-versioning@w3.org
> Subject: AW: UPDATE semantics for checked-out resources
>
>
> This is true, but it does not apply to the more general case of an 
> UPDATE
> of a version.controlled collection containing a checked-out resource 
> which is not identified
> by the DAV:version-controlled-binding-set of the update source.
>
> Cheers, Manfred
> -----Ursprüngliche Nachricht-----
> Von: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff 
> T
> Gesendet: Freitag, 27. September 2002 14:00
> An: ietf-dav-versioning@w3.org
> Betreff: RE: UPDATE semantics for checked-out resources
>
>
> I agree with your conclusion, but I believe this follows from
> the DAV:no-overwrite-by-auto-update precondition for CHECKIN, i.e.:
>  If the DAV:auto-update property for the checked-out resource
>  identifies a version-controlled resource, at least one of the
>  versions identified by the DAV:predecessor-set property of the
>  checked-out resource MUST identify a version that is either the same
>  as or a descendant of the version identified by the DAV:checked-in
>  property of that version-controlled resource.
> If the VCR is checked-out, there is no DAV:checked-in version,
> which means this precondition would not be satisfied.
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Friday, September 27, 2002 4:48 AM
> To: Clemm, Geoff
> Cc: ietf-dav-versioning@w3.org
> Subject: Re: UPDATE semantics for checked-out resources
>
>
> While we're at this topic: we have a similar issue with auto-update of
> version controlled collections.
> - checkout a versioned collection with apply-to-version
> - remove a member from the working collection
> - checkout in-place the member of the versioned controlled collection
> - checkin the working collection
> -> the version controlled collection should be updated an remove
>    the binding to the checked-out resource.
> I think the checkin should fail in this case, as the removal of
> a checked-out member might cannot be permitted.
> Do you agree?
>