RE: request for un-version-control feature

Could you motivate the need to unversion-control a resource
but not delete it?  In particular, should a server that automatically
puts all resources under version control fail such a request,
or just ignore it?

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:[email protected]]
Sent: Friday, February 07, 2003 12:27 PM
To: [email protected]
Subject: request for un-version-control feature



Hi.

As far as I know, there has been a long discussion about whether this
feature is required or not. Fact is, it's missing from RFC3253, yet several
systems need a way to implement it.

Several workaround have been discussed, but IMHO all of them have some
disadvantages, and furthermore there's no interoperability here:

1) COPY to new resource / DELETE old / MOVE back

Disadvantage: creates new resource (ACLs are lost, DAV:resource-id changes),
requires multiple steps


2) DELETE on version history resource

Disadvantage: actually requires that VHRs are supported, also it's quit
possible that the version history should be preserved


3) PROPPATCH/remove on live properties such as DAV:checked-in,
DAV:checked-out or DAV:version-history

Disadvantage: messy and breaks RFC3253 (because the properties are
protected).


Therefore I think that an (optional) new method "UNVERSION-CONTROL" makes
most sense. Servers won't need to support it, and it's presence can easily
be detected using OPTIONS and PROPFIND/supported-method-set.

I can think of one optional parameter that would be marshalled in the
request body: whether the version history should be deleted as well or not.

Feedback appreciated,

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760