RE: request for un-version-control feature

I agree that DeltaV needs a real and standardized way to make a resource
unversioned. Work-around proposals so far have not met the requirements
for the feature.

> Note that there are use cases for deleting the history of a resource
> (which is marshalled by issuing a DELETE request against the
> version-history resource).  What has not been demonstrated is the need
> to "disconnect" a resource from its history without deleting the
> history.

Here's the use case that demonstrates the need.

First, a resource exists -- foo.doc. It is version-controlled.  I 
decide to make foo.doc a regular resource. Why? Could be any of a 
number of reasons:
 - It was a mistake to make it versioned in the first place
 - My quota isn't big enough for all the old versions.
 - The resource is now published (publicly readable), not being 
   authored, so it's no longer appropriate to show or track 
   changes via versioning

So far, this motivates the basic need to have the content at URL 
"foo.doc" not be versioned... Now some side requirements:
Although I want "foo.doc" to be unversioned, other things should 
stay the same.  Among these things:
 - The creationdate should not change
 - The user who created it should not change, nor should the owner
 - Permissions should not be re-initialized or changed
 - If there's a file access history, that should still be there
 - If foo.doc is locked, the lock should stay.
 - Other characteristics like tickets should not change.

The unversion use case may need to be supported in any repository 
where both versioned and unversioned resources exist. Users make 
mistakes, and they like to undo mistakes without making themselves 
even worse off.

The unversion problem, if not dealt with via a standard and well-behaved
mechanism, could become the same as the "safe-save" problem which 
Julian has documented on the WebDAV.  When a client does a safe save to 
a resource like "foo.doc", the client often does something like this:
 1. PUT foo.doc~
 2. HEAD foo.doc~
 3. DELETE foo.doc
 4. MOVE foo.doc~ to foo.doc

When a user's client "safe saves" their document, the user is surprised
if 
the file's permissions change. Yet it's very common for the server to 
apply a set of default permissions to "foo.doc~" when it's created, 
and then the custom permissions on "foo.doc" are lost when that one
is deleted.

If clients start to do (1) COPY foo.doc to foo.doc~, (2) DELETE foo.doc,

(3) MOVE foo.doc~ to foo.doc in order to accomplish unversioning, then
we'll just see more safe-save type garbage.

Lisa

Received on Friday, 14 February 2003 18:58:29 UTC