RE: Cascading creation of collections

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Mittwoch, 13. Februar 2002 14:51
> To: Ietf-Dav-Versioning (E-mail)
> Subject: RE: Cascading creation of collections
> 
> 
>    From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
> 
>    Environment: workspaces WS1 and WS2 version-controlled
>    collections. MKCOL creates version-controlled collectins by
>    default.
> 
>    Suppose following sequence of changes each made with a 
> single activity
> 
>    Activity A1  MKCOL /WS1/A       Version WSV1 w. binding A, 
> Version AV1 w.
>    binding NULL
>    Activity A2	 MKCOL /WS1/A/B     Version AV2 w. 
> binding B, Version BV1 w.
>    binding NULL
>    Activity A3  MKCOL /WS1/A/B/C   Version BV2 w. binding C, 
> Version CV1 w.
>    binding NULL
>    Activity A4  MKCOL /WS1/A/D     Version AV3 w. binding B,D 
>  Version DV1
> w.
>    binding NULL
> 
>    Despite the dépendecies of the activities/changes perfromed above
>    activity A4 is merged into WS2 w/o merging A1 trough A3.
> 
>    Activity A4 contains versions AV3 and DV1.  Due to the MERGE
>    behavior this MERGE must fail cause collection /WS2/A does not
>    exist yet. Therefore no merge target exists.
> 
> The MERGE of A4 into WS2 succeeds, but produces no effect on WS2
> (because there are not VCR's for the version histories of AV3 or DV1
> in WS2).  If the client wants to detect this, it needs to first use
> the DAV:merge-preview REPORT, which will return AV3 and DV1 in
> ignore-preview elements.
> 
>    That is, to propagate
>    activity A4 first activity A1 has to be propagated, what 
> would cause the
>    creation of /WS2/A.
> 
> Yes, if by "propagate" you mean "expose the versions in the
> DAV:activity-version-set".
> 

Propagate = MERGE

>    A subsequent MERGE of activity A4 would cause the creation of
>    /WS2/A/D.  In this case the server can even set the checked-in
>    version to the "right" one, cause the activity contains the "right"
>    version for /WS2/A/D in its activity-version-set property.
> 
> Yes.
> 
>    For the other binding B there is no version known. If the 
> server does no
>    guessing of versions and just sets it to version BV1 or 
> leave it blank.
> 
> Actually, it can't leave it "blank" ... it has to pick some version,
> and if BV1 is the only version, that will be the one it will have to
> pick.
> 
>    The cascade of creations would stop here.
> 
> Yes.
> 
>    If the server would look up the MERGE source and uses the
>    checked-in version there to guess the checked-in version of
>    /WS2/A/B then the cascade would go on. Right so far?
> 
> Can you be more specific about what you mean by "look up the 
> MERGE source",
> and how that would help it guess the checked-in version of /WS2/A/B?

Well the MERGE request gives source and destination. So if WS1 is merged
into WS2 the source is clear to be WS1. With that I know the VCR's/VCC's of
WS1 for instance /WS1/A, /WS1/A/B, /WS1/A/D. For every binding stored with
collection version AV2 (that is B and D I could find the corresponding vcr
in WS1 and read the checked-in version property)

But anyway the MERGE done above was made merging an activity into an
workspace. In this case there is no way of guessing right, cause the
checked-in version of /WS1/A/B is not stored anywhere and the VCC that was
used for checkout of the collection version AV2 is not known within the
activity.
To give the server a chance of right guessing in this case, there has to be
some more informaton to be maintained by the server internally. But even
that could be ambigious in some cases. And maybe the effort implementing it
would not equal the income ...

> 
>    This rises a question dealing with populating a workspace with
>    reference to another worksapce using VERSION-CONTROL Geoff
>    described few days ago. If the server does no guessing then the
>    cascading creation of the resource tree would stop after depth 1???
> 
>    Or do I miss a detail here?
> 
> Suppose you did VERSION-CONTROL to set the version selected
> by /WS2/A to be AV2.  The server will automatically create the VCR
> /WS2/A/B.  The server gets to pick which version to initialize the
> new VCR with, and suppose it picks BV2.  Then it has to automatically
> create the VCR /WS2/A/B/C, has to pick which version to initialize
> this new VCR with.  So in general, if the server picks versions
> that have members, it can end up populating an entire tree as
> the result of a single VERSION-CONTROl request.
> 

So it is the way I expected it. Leaving the checked-in version blank would
have been very obscure.


Regards
Daniel

Received on Wednesday, 13 February 2002 09:10:30 UTC