- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 11 Dec 2001 20:09:30 -0500
- 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 version-controlled 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 belongs? 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? Cheers, Geoff
Received on Tuesday, 11 December 2001 20:10:02 UTC