W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Problems with Delete of a version-controlled collection

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 16 Jan 2002 11:49:50 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEB3@SUS-MA1IT01>
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>

   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]

   suppose this:

	   +- /bar
		+- foobar.c

   all the resources are under version-control. Now suppose this
   sequence of requests:

   CHECKOUT /foo/bar

   (working-collection: /wc/wc1  auto-update: /foo/bar)

   CHECKOUT /foo

   (working-collection: /wc/wc2, auto-update: /foo)

   delete folder /foo/bar:
   DELETE /wc/wc2/bar   
   or is it done via the real VCR? I hope not! The DELETE should be hidden
   until checkin!

You are correct.  The DELETE should be done to the working collection,
as you show here.

   CHECKIN /wc/wc2
   (applied to /foo -> the folder /bar and all its content is gone)

   CHECKIN /wc/wc1
   (must fail because the VCR the auto-update should go to is gone)

That depends on the server.  A server could just delete the
auto-update property when the VCR referenced by that property
is deleted, and allow the CHECKIN of /wc/wc1 to succeed.
You haven't really "lost" anything, because this version is
now available in the version history that is associated with

   1. Is this right?
   2. If yes: Shouldn't the deletion be prevented or fail because a
   is checked out and therefore some kind of "locked"?

A server certainly could fail the CHECKIN of /wc/wc2 for this reason,
but that would have to be a server-defined precondition (i.e. this
CHECKIN is not forbidden by any of the standard preconditions).

Received on Wednesday, 16 January 2002 11:50:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC