RE: Re[4]: Re (2): Creating new version-controlled bindings refer encing existing VHR's

No, creating no VCR is not legal (i.e. you must create the VCR).
If there is a VCR there, the client can update it to see a better
version than the one the server picked for it, but if no VCR was
created, the client is stuck with a "bad" namespace.

I hope it's OK that I posted this back to the deltav mailing list -
it is a good question.

Cheers,
Geoff

-----Original Message-----
From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]
Sent: Friday, December 14, 2001 1:08 PM
To: Clemm, Geoff
Subject: Re[4]: Re (2): Creating new version-controlled bindings refer
encing existing VHR's



Is it a valid "server-defined behavior" to select no version at all?
I.e. not create version-controlled resource for collection member in
MERGE/UPDATE/VERSION-CONTROL methods when member version is not
specified? (and it can not be specified in UPDATE/VERSION-CONTROL
methods according to specification)
Because other policies (choosing initial, random or most recent
version seems to be no more useful). If version selected in such case
is not defined by specification, it means that client should not make an
assumption about which version will be chosen. So, is there any sense in
creating versioned-resource for such ember?


Friday, December 14, 2001, 8:47:40 PM, you wrote:

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

CG>    If I do UPDATE on version-controlled-collection in some workspace,
CG>    what should I do with version-controlled resource - members of this
CG>    collection. Version of version-controlled-collection contains
CG>    bindings <name, version-history>. Workspace provides binding of
CG>    version-history to versioned-resource. If version of
CG>    version-controlled-collections is changed by UPDATE, what should I
CG>    do with versioned-resources, which vresion-histories are no more
CG>    members of this collection? Delete?

CG> Yes.  This is defined in the
CG> DAV:update-version-controlled-collection-members postcondition from
CG> section 14.11 (Additional MERGE and UPDATE semantics for
CG> version-controlled collections).

CG>    More interesting - what should I do with new members, i.e. version
CG>    histories of which were not in bindings of previous version of
CG>    collection. Should I create versioned-resource to provide
CG>    <workspace,version-history> -> versioned-resource binding?

CG> Yes.

CG>    But which version should this versioned-resource select by
CG>    checkedIn/checkedOut property? Once again, UPDATE source is version
CG>    and there is no information about source workspace.
CG>    Looks like it is once again up to the server which version to choose?

CG> Yes.

CG>    Well, for me it means that UPDATE should not be used at all for
CG>    version-controlled collections because result is unspecified.

CG> UPDATE is much less common than MERGE, and even less common in the
CG> case of version-controlled collections - you would much more likely be
CG> updating a baseline controlled collection with a new baseline, rather
CG> than updating an individual version-controlled collection.

CG>    But UPDATE is is special case of MERGE (if MERGE target is successor
CG>    of MERGE source).

CG> No, MERGE is much more flexible than UPDATE.  In particular, you
CG> commonly MERGE a collection of version controlled resources (as
CG> opposed to an individual collection version), or you MERGE an
CG> activity.  In the first case, the MERGE of a collection merges all of
CG> the members of the collection as well.  In the case of MERGE of an
CG> activity, if the activity created a new version of collection that has
CG> a new version history in it, the activity probably also has the
CG> initial version of that version history in it as well.

CG>    Does it mean that I also can not use MERGE to
CG>    correctly merge two versions of version-controlled-collection
CG>    (belonging to the same version history)?

CG> You can, but it probably will be occurring in the context of
CG> a more general activity or VCR collection merge.

CG>    In any case I think that answer for these questions should be
included
CG>    in specification, because it is not behavior of
CG>    MERGE/UPDATE/VERSION-CONTROL methods
CG>    applied to version-controlled-collection in a workspace is not
CG>    obvious (at least for me).

CG> I believe it is "well-defined" in the spec, but I agree that it is
CG> not "obvious".  Unfortunately, it is not always clear how to make
CG> something obvious (since it is so reader-dependent), but we need to
CG> get appropriate entries into the FAQ to address this.

CG> Cheers,
CG> Geoff



-- 
Best regards,
 Konstantin                            mailto:KKnizhnik@togetherlab.com

Received on Friday, 14 December 2001 13:20:39 UTC