RE: Confusion: Removing a resource from version control

A version-controlled resource is really just a handle to a version resource
contained within a version-history resource. There could be many
version-controlled resource pointing to the same version. Deleting a version
when deleting a version-controlled resource does not make any sense.

What is not clear is how a client can delete a version or version-history
resource when the server only supports the version-control feature. Maybe
what needs to be stated is a version-history resource MUST be deleted when
the version-controlled resource is deleted if the server only supports the
version-control feature.

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: Tuesday, June 12, 2001 4:54 PM
To: 'Rick Rupp'; ietf-dav-versioning@w3.org
Subject: RE: Confusion: Removing a resource from version control 


I was not planning on implementing a version-history feature.  I see
absolutely no problems with supporting the working resource feature with
anything I've said.  I wasn't planning on supporting workspaces, but I don't
see any problems there that aren't inherent in being able to delete
individual versions.

Although you can keep an object around that allows you to retrieve the
version history of a completely deleted resource, I don't understand how
that can be done without eventual name collisions.

Say I create foo/bar.txt as a version controlled resource.  If I wanted a
separate version history object, I could put it in some place like
/vhist/foo/bar.txt
Now someone wants to delete foo/bar.txt -- OK, I delete it but not
/vhist/foo/bar.txt

That works until someone tries to create a new foo/bar.txt that they wish to
be a version controlled resource.  I have a collision with
/vhist/foo/bar.txt and THIS foo/bar.txt is completely distinct from the
original.






-----Original Message-----
From: Rick Rupp [mailto:Rick.Rupp@merant.com] 
Sent: Tuesday, June 12, 2001 4:22 PM
To: 'John Hall'; 'ietf-dav-versioning@w3.org'
Subject: RE: Confusion: Removing a resource from version control 


I disagree that version history should be deleted if you delete the version
controlled resource. Section 5 of the draft clearly states the version
history resource exists in a server defined namespace and therefore is
unaffected by any deletion or movement of a version controlled resource.
If you require the version history to be deleted you will cause serious
problems for a server that supports the workspace and working resource
feature.
-----Original Message----- 
From: John Hall [mailto:johnhall@evergo.net] 
Sent: Tuesday, June 12, 2001 3:52 PM 
To: 'Clemm, Geoff'; 'DeltaV' 
Subject: RE: Confusion: Removing a resource from version control 


Intro about me at bottom. 
"In order to remove a resource at a given URL from version control, the 
client can replace the resource under version control with a 
non-version-controlled copy of that resource.  For example, a client can 
COPY the version-controlled resource to a temporary location, DELETE the 
version-controlled resource, and then MOVE the copy from the temporary 
location back to the original URL.  Note that the versions already 
created for the version-controlled resource will continue to exist at 
their server-defined locations." 
Is that clearer? 
Cheers, 
Geoff 
================================================================= 
When you DELETE a version-controlled resource, I strongly believe that 
all information for that VCR and all versions already created should go 
to the great bit bucket in the sky. 
As I understand your formulation, I would have severe problems in 
modifying my DAV server (with versioning support) to support DELTAV 
using this behavior.  
I would prefer this formulation / behavior: 
"In order to remove a resource at a given URL from version control, the 
client can replace the resource under version control with a 
non-version-controlled copy of that resource.  For example, a client can 
COPY the version-controlled resource to a temporary location, DELETE the 
version-controlled resource, and then MOVE the copy from the temporary 
location back to the original URL.  Note that the versions already 
created for the version-controlled resource will NO LONGER BE AVAILABLE. 
If you wish to remove a resource at a given URL from version control 
while also retaining a previous revision history, then you should MOVE 
the resource to a new save location and COPY the current version back to 
the original URL." 
========== 
My formulation is based explicitly on the idea that some implementations 
and some customers are not keeping track of legal documents and 
therefore deleting old versions is highly desired if not required.  A 
server shouldn't be forced to keep data that a client is willing to 
specifically state that it doesn't want. 
I think a far better manner of achieving your goals is simply to allow 
the VERSION-CONTROL method to turn version-control for a resource at a 
given URL off (if supported by the server).  That allows you to achieve 
your above objectives (no new versions, but keep the old ones at the 
same URLs) without changing the usefulness of the DELETE command. 
====================================================== 
John Hall is an engineer working on the Xythos development team to 
modify their DAV (with revision additions) server to support DELTAV as 
well as other-party proprietary DAV versioning systems.