Cascading creation of collections

HI,

this is just for clearification of my understanding:

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. That is, to propagate
activity A4 first activity A1 has to be propagated, what would cause the
creation of /WS2/A. 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. 
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. The
cascade of creations would stop here.
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?

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?


Regards,
Daniel

Received on Wednesday, 13 February 2002 04:10:23 UTC