RE: Deleting versions

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: 25 May 2001 17:58
> To: DeltaV
> Subject: Deleting versions
>
>
>
> I know not all implementations of DeltaV will allow deleting old versions,
> but the specifications specifically allows it.  I've been looking
> into that
> functionality and encountered some issues and questions.
>
> #1)  Is there some way of finding out, before trying the delete, if it's
> possible to delete a version?  Before you say
> "supported-method-set", allow
> me to point out that this property is not shown to exist on versions.

Sure it is.  All resource properteis described in versioning-15 sec 3.1
states "The version-control feature introduces the following REQUIRED
properties for any WebDAV resource.", and since "The version-control feature
MUST be supported if any other versioning feature is supported." it follows
that you can always ask a versioning resource for its supported methods.

> #2) It looks like there's a set of error msgs the server can return if it
> decides to prevent the user from deleting the referenced version, the root
> version, or all versions.  What error msg should the server return if it
> decides to prevent the user from deleting the "current" version
> (though one
> that is not checked out)?

Please clarify what you mean by the "current" version?

> Or what if the server decides to prevent the only
> remaining version from being deleted?

This case is not called out by the spec., so I would expect 403 Forbidden
with no interoperable extended error info.  Just as there will be other
cases that servers (say for implementation reasons) refuse methods and have
interop way of explaining why.

> #3) I don't understand the following text from 3.12:
> "(DAV:update-predecessor-set): If a version is deleted, any reference to
> that version in a DAV:predecessor-set MUST be replaced by a copy of the
> DAV:predecessor-set of the deleted version."  Does that mean that before
> deleting a version, the client must munge the predecessor-set
> properties of
> a bunch of other versions?

Yes, potentially.  The postcondition is required to fix up the history to
show a continuous ancestry for the remaining versions.

> But the predecessor-set is protected!

... from clients.  There are many examples of protected properties that a
server can/will modify.

> Or does
> it mean that the server must update the predecessor-set before performing
> the action, and if it cannot, it returns the error msg?  Please
> explain this
> better in the draft & to the list...

It is a postcondition of the DELETE method for a version, therefore if it
cannot be made true it MUST be as though the method was never sent.  No
partial results will be left by the server, whether the fix up is done
before/after the action is up to the implementation -- the spec states
effectively that by the time 'the response is dispatched' the postcondition
is true.  This is the same for all methods (not just DeltaV).

> #4) Can situations arise where resources can have no versions?

No.  Take a look at the 3.12 postcondition
	(DAV:must-be-root-version): If the root version of a version history is
	deleted, there MUST be another version that is the new root version,
	i.e. that is the ancestor of all other versions in the version history.

> I can
> actually think of two ways this might be achieved:
>  - A client deletes all the versions (but not the version-controlled
> resource)

See above.

>  - A null resource gets versioning turned on but no body is added

A what? <g>

> Must clients be able to deal with VCRs with zero versions?  If
> not, then we
> need to make a requirement on servers that they must not ever create a VCR
> with zero versions.

The way to create a version-controlled resource is with VERSION-CONTROL
which always creates a version-controlled resource based on a version.  If
the target resource was versionable the new version is created, or the
VERSION-CONTROL can reference an existing version in the request body.

Tim

Received on Friday, 25 May 2001 17:43:14 UTC