- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 13 Feb 2002 08:50:59 -0500
- To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
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". 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? 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. Cheers, Geoff
Received on Wednesday, 13 February 2002 08:51:31 UTC