W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Cascading creation of collections

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 13 Feb 2002 08:50:59 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B105CE0E27@SUS-MA1IT01>
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

   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
   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

   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.

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

   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?

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.

Received on Wednesday, 13 February 2002 08:51:31 UTC

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