RE: Confusion: Removing a resource from version control

From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
Sent: Tuesday, June 12, 2001 6:08 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Confusion: Removing a resource from version control 


> But a versioning *unaware* clients will also be issuing a DELETE
against a version-controlled resource on a versioning 
> server that supports workspaces, and reasonable behavior must result.
Blowing away all versions of that resources 
> from all other workspaces is not a reasonable result.

I fail to see what this is not a reasonable result, either in the
presence of workspaces or not.

Without workspaces, it is the normally expected behavior.  It is the
behavior a user is used to when they say "del foo.txt"  oops "rm
foo.txt".  It is the expected behavior they get when they issue a DELETE
on a DAV server.  It is the expectation of customers building simple
clients.

"Least Surprise".  If you don't know anything about a server
implementation, they only thing safe to assume is that DELETE means
DESTROY.

"Greater Burden".  The more sophisticated client should have a greater
burden than the less sophisticated client.  A simple non-workspace
client should not have to jump through hoops to make it easier to write
a more complex client that uses workspaces.  If necessary, add a XML
item to the DELETE VCR that would say <!ELEMENT retain-old-versions
EMPTY>, again keeping the burden on the new clients and the more
sophisticated clients not the older and less sophisticated ones.  If you
change the spec so that the default MAY blow away all old versions when
you delete the VCR I'd be happy to say that such behavior MUST also
support retain-old-versions.

Now, the workspace element "workspace-checkout-set" name seems to imply
that a workspace only references checked out versions.  So what would be
the problem?  A DELETE should fail on an item that is in a checked-out
state, so the fact that a workspace has references to checked out
versions isn't a problem.  Perhaps you should define a 'checkout-count'
on a VCR when operating in the presence of workspaces.

If the workspace refers to non-checked out versions, then there is
always the "404 Not Found" error code.  I see no reason why a client
shouldn't handle, and be prepared to handle, that case.  It matches a
client that is storing its state on local disk, like most source control
systems.  A 'sync' will note that a resouce is no longer found and
delete it from the local copy.

This does not prevent your implmentation from keeping around all old
versions.  It does mean we don't have to ask our customers to increase
their complexity in order to get simple functionality.

=====================

In summary, I think it is unreasonable not to allow a server to blow
away all versions when the VCR is deleted.  It is a natural
implementation which satisfies customer desires and expectations.  Nor
do I think the implementation of this behavior in my server precludes
your server implementation, or makes it difficult for your more
sophisticated client to be interoperable.

Peace

Received on Wednesday, 13 June 2001 17:22:28 UTC