W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Confusion: Removing a resource from version control

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT