RE: MOVE on Version History Members of a Working Collection

   From: Zivkov, Sasa [mailto:sasa.zivkov@sap.com]

   > You will actually have one VCR, with two bindings to it (i.e. one from
   > mycoll/a.txt and another from mycoll2/a.txt).  This is required by
   > workspace semantics, which says that there can only be one VCR in a
   > workspace for a given version history, but you can have multiple
   > bindings in that workspace to that VCR.

   I always thought that there can be only one URL in a workspace for
   one VCR :-(

No, it is inherent in namespace versioning that you can encounter
multiple URL's for the same VCR (in particular, whenever you move,
and then restore the old version of the origin collection, you will
always end up with two collections containing the same VCR.

   So, there is not *the* URL of a VCR in a workspace ?

No, a VCR can have multiple URL's in a workspace that map to it.

   In the example above if both URL's mycoll/a.txt and mycoll2/a.txt are
   the same VCR then they must share the same set of live/dead properties
   and content.
   Right ?

Same content, dead properties, and RFC3253 live properties, yes.  For
other live properties, you cannot say (since the semantics of live
properties is unconstrained).

   And if I DELETE mycoll/a.txt is the VCR deleted also ?

DELETE removes just the specified binding to a resource,
unless there are some extra semantics defined for a DELETE
of that kind of rsource.  If that is the last binding
to a resource, it becomes inaccessible (through the protocol).

   Or does the server do the reference counting and deletes the VCR when
   the last binding to it is deleted ?

Whether or not the resource is "destroyed" or "obliterated" as a
result is server dependent.  In particular, there may be other protocols
that still provide access to the state of that resource.

   Also if we take a look on a part of rfc3253:

       14.4 Additional DELETE Semantics

	 Additional Preconditions:

	     (DAV:cannot-modify-checked-in-parent): If the request-URL
	     identifies a version-controlled resource, the DELETE MUST fail
	     when the collection containing the version-controlled resource
is
	     a checked-in version-controlled collection, unless DAV:auto-
	     version semantics will automatically check out the version-
	     controlled collection.

   So, here you mention *the* collection containing the VCR.
   But in the example above which collection is *the* collection containing
   the VCR mycoll or mycoll2 ?

You can talk about "the" collection in the context of a particular URL
(as in the case cited above, where there is a request-URL).  In
particular "the" collection of a resource wrt a particular URL is the
collection identified by the URL formed by stripping off the last
segment of the URL.  That is the collection whose state will be modified
by the DELETE (since the bindings are part of the state of the collection).

Cheers,
Geoff

Received on Wednesday, 5 June 2002 15:16:06 UTC