- From: Rick Rupp <Rick.Rupp@merant.com>
- Date: Tue, 12 Jun 2001 16:22:06 -0700
- To: "'John Hall'" <johnhall@evergo.net>, "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
- Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF5036B427A@beavmail.merant.com>
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:31:50 UTC