W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

RE: Re (2): Creating new version-controlled bindings referencing existing VHR's

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 11 Dec 2001 20:09:30 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1052AD11B@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]

   So the only way to do it - is to place source collection under
   baseline control???

If you want to recreate a previous state of the source collection
from history, yes.  A baseline is the "deep-version" of a collection
that captures the state of all members of the collection.  You can
think of it as a set of versions (i.e. one version of each
resource in the collection, including each version-controlled collection).

   But what is the result of applying VERSION-CONTROL method with
   <DAV:version> refers to version-controlled-collection? It will create
   version-controlled resource in the target workspace for this collection
   iself but not for its members, right?

If there already is a version selected by that workspace for a given
version history, then that version is selected.  Otherwise, it is
server defined (e.g. a server could just pick the initial version,
the latest version, or some random version).

   What in this case is the result of PROPFIND
   with Depth=infinite applied to such version-controled-resource?

Depends on what version the server selected.

   Is there any good motivation for restricting VERSION-CONTROL source to
   be a version and not a version-controlled-resource, which capture
   information about the resource version and workspace to which it

Yes, the rationale is in the protocol document in the section on
version-controlled collections.  The collection version is used for
activity change set information, to capture the delta between a
previous version of that part of the namespace.  But the bottom line
is that if you want a version of the whole tree, you use a baseline,
and if you want incremental information about the namespace you use a
collection version.

   It seems to me that the current model of version-control method for
   existed version history is contradicting and not clear...
   If the only way of importing information in workspace from other
   workspaces is baseline, then we should prohibit version-control method
   for existed version history at all. Otherwise, version-control method
   should be able to correctly place the whole specified subtree in the
   target workspace.

A collection version and a baseline address different use cases.  It
appears that your use cases are addressed by the baseline feature, and
so that is the one you would use.  Why would you want another feature
(version-controlled collections) to do the same thing?

Received on Tuesday, 11 December 2001 20:10:02 UTC

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