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

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

From: Konstantin Knizhnik <KKnizhnik@togetherlab.com>
Date: Fri, 14 Dec 2001 19:55:08 +0300
Message-ID: <194116620441.20011214195508@togetherlab.com>
To: "Clemm, Geoff" <gclemm@rational.com>
CC: ietf-dav-versioning@w3.org
Sorry, I have one more question about this topic:
If I do UPDATE on version-controlled-collection in some workspace,
what should I do with version-controlled resource - members of this
collection. Version of version-controlled-collection contains bindings
<name, version-history>. Workspace provides binding of version-history
to versioned-resource. If version of version-controlled-collections
is changed by UPDATE, what should I do with versioned-resources, which
vresion-histories are no more members of this collection? Delete?

More interesting - what should I do with new members, i.e. version
histories of which were not in bindings of previous version of
collection. Should I create versioned-resource to provide
<workspace,version-history> -> versioned-resource binding?
But which version should this versioned-resource select by
checkedIn/checkedOut property? Once again, UPDATE source is version
and there is no information about source workspace.

Looks like it is once again up to the server which version to choose?
Well, for me it means that UPDATE should not be used at all for
version-controlled collections because result is unspecified.
But UPDATE is is special case of MERGE (if MERGE target is successor
of MERGE source). Does it mean that I also can not use MERGE to
correctly merge two versions of version-controlled-collection
(belonging to the same version history)?
In any case I think that answer for these questions should be included
in specification, because it is not behavior of
applied to version-controlled-collection in a workspace is not
obvious (at least for me).

Wednesday, December 12, 2001, 4:09:30 AM, you wrote:

CG>    From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]

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

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

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

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

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

CG> Depends on what version the server selected.

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

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

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

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

CG> Cheers,
CG> Geoff

Best regards,
 Konstantin                            mailto:KKnizhnik@togetherlab.com
Received on Friday, 14 December 2001 11:59:05 UTC

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