RE: Deleting versions

   From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   "Lisa Dusseault" <lisa@xythos.com> wrote:

   > Geoff said:

   > 2.  I don't think the issue of a version-controlled-resource with zero
   > versions is sufficiently addressed.  For your convenience, here's the
   > section from 2518:
   > ...
   > A direct read of this paragraph combined with deltaV draft 15 (and your
   > implication) would indicate that you can't issue a VERSION-CONTROL
method
   > on a lock-null resource.  That's bogus.

   No, that's great!<g> The lock null resource is a nonce concept that
   is not required by Delta-V.  Reading the quoted paragraph with
   Delta-V gives (IMHO) the correct impression that versioning
   operations are not allowed on lock null resources.

Another reason that we do not require a server to support putting a
"null" resource under version control is that some version control
systems cannot put a resource under version control until they know
what kind of resource it is.  For example, a collection often requires
a very different kind of version history resource from a text
document.

   > A "write locked null resource"
   > is there so that the creator can do all the write operations and state
   > changes they need before making the resource visible to everybody.

   This isn't true since you cannot PROPPATCH a lock null resource,
   and as soon as the first PUT/MKCOL succeeds it is no longer in the
   lock-null state -- so there really is no set of state changes that
   can be applied to a lock null resource.

I agree.

   > So, I suggest that VERSION-CONTROL (and perhaps other methods
   > like CHECKOUT, MKWORKSPACE...) should be explicitly allowed by
   > DeltaV to be done on write locked null resources, and that the
   > spec define a precondition that can be returned if the server
   > decides not to allow operations on write-lock resources.

   I see no argument for VERSION-CONTROL or CHECKOUT, but MKWORKSPACE is a
   more likely candidate since it is akin to MKCOL.  This would obviously
   require a modification to RFC2518's statement that the lock null resource
   MUST fail methods that are not in the named list.

I agree that it does at least make sense to allow MKWORKSPACE (and
MKACTIVITY) to apply to lock null resources, but since creating a lock
null resource before issuing the MKWORKSPACE provides little or no
benefit, and since the concept of a lock null resource is so bogus
(:-), I would prefer not mentioning lock null resources in the
versioning protocol unless a pressing need to do so is identified.

Cheers,
Geoff

Received on Saturday, 2 June 2001 16:24:09 UTC