RE: Confusion: Removing a resource from version control

One additional note:

The key relationship between a checked-in version-controlled resource
and a version resource is that the DAV:checked-in property of a VCR
contains the URL of a version resource.

Some of the options open to a server when an explicit request to
DELETE a version identified by a DAV:checked-in property include:

- fail the DELETE
- allow the DELETE, and return a 404 when a client later attempts
  to perform some operation on the URL from the DAV:checked-in property
  of the VCR

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Tuesday, June 12, 2001 10:15 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Confusion: Removing a resource from version control 



   From: Rick Rupp [mailto:Rick.Rupp@merant.com]

   A version-controlled resource is really just a handle to a version
   resource contained within a version-history resource.

It's best to think of them as three totally separate and distinct
resources.  A checked-in version-controlled resource does display the
same content and dead properties of another totally separate resource
(the version resource identified by the DAV:checked-in property),
but it is not a "handle" or "pointer" or "reference" to that resource
in any significant way.

   There could
   be many version-controlled resource pointing to the same
   version.

Yes.

   Deleting a version when deleting a version-controlled
   resource does not make any sense.

Yes, in the context of many version-controlled resources
associated with the same version history, this deletion
does not make sense (just because one workspace is no longer
interested in it, does not mean other workspaces aren't).

   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.

A version resource has a URL assigned to it when it is created.
If you issue a DELETE request against that URL, that version is
deleted (assuming you have permission to do so).  The URL for
versions can be obtained from the DAV:checked-in property,
the DAV:version-tree report, and the DAV:predecessor-set and
DAV:successor-set properties of another version resource.

   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.

If the server only supports the version control feature, then there
is no version history resource visible in the URL namespace, so a
client wouldn't know if it was deleted or not (:-).  The key here
is that the behavior of DELETE has to be consistent, whatever
feature set is supported by the server, so you can't have 
DELETE do incompatible things depending on what versioning features
are supported (not if you want to make it feasible to write
interoperable clients).

Cheers,
Geoff

Received on Wednesday, 13 June 2001 07:33:49 UTC