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. 

Received on Tuesday, 12 June 2001 19:53:42 UTC