RE: 3 workspaces and merges

When merging ACT3 into WS3, you are telling the server that you just
want the "delta" implied by ACT3.  The delta is that there is a new
member of A (called C) and that there is a new version of C (CV1).  If
the client (or the server) decides to "restore" A/B as part of the
merge, the server has no way of guessing which version of B should be
restored, so it just picks some arbitrary version (possibly the
initial version).

If on the other hand, baselines were created and merged (instead of
the activities), the baseline from WS2 would know what version of B
was selected at the time the baseline was created, and would select
that version to be the result of restoring A/B.

Cheers,
Geoff

-----Original Message-----
From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
Sent: Tuesday, February 12, 2002 8:56 AM
To: Ietf-Dav-Versioning (E-mail)
Subject: 3 workspaces and merges


Hi,

this one is a bit more tricky. Look at this:

There are 3 workspaces WS1,WS2,WS3. 
In WS1 there is a tree of resources as follows:

	WS1 (checked-in: WS1V1)
	 |
       +-- A (checked-in: AV1)
           |
           +-- B (checked-in: BV1)
           |   |
           |   +-- F (checked-in: FV1)
           |
           +-- X (checked-in: XV1)

WS2 was created in reference to W1. WS3 was created in reference to WS2.
All workspaces containing version-controlled resources/collections sharing
their version-histories. Noc changes made in WS2 and WS3 after creation.

Now there is a change in WS1: A gets a new member Y and B is deleted,
resulting in a new version of A (AV2) and a version for Y (YV1). This change
was made using activity ACT1.

Now workspace WS1 looks this way:

	WS1 (checked-in: WS1V1)
	 |
       +-- A (checked-in: AV2)
           |
           +-- X (checked-in: XV1)
           |
           +-- Y (checked-in: YV1)

WS2 and WS3 still not changed at all. Now the change in WS1 has to be
propageted to WS3. This is done with MERGE oft ACT1 into WS3. With that WS3
looks like WS1:

	WS3 (checked-in: WS1V1)
	 |
       +-- A (checked-in: AV2)
           |
           +-- X (checked-in: XV1)
           |
           +-- Y (checked-in: YV1)

So far so good nothing strange happend til now.
In WS2 in ACT2 a new version of /WS2/A/B/F was checked in. 
In ACT3 A gets a new member C. With all that WS2 looks this way:

	WS2 (checked-in: WS1V1)
	 |
       +-- A (checked-in: AV3)
           |
           +-- B (checked-in: BV1)
           |   |
           |   +-- F (checked-in: FV2)
           |
           +-- X (checked-in: XV1)
           |
           +-- C (checked-in: CV1)

After all that actions there is a version tree of A looking this way:

	 AV1
	 | \
       |  \
     AV2   AV3
	 
With checked-in version of /WS1/A and /WS3/A is AV2 and checked-in version
of /WS2/A is AV3.

So finally the starting point is constructed. Let the show begin:

MERGE ACT3 into WS3
That is the new member C of A has to appear in WS3. Due to the fact that
version AV3 of the merge source /WS2/A is not a successor of the version AV2
of the merge destination /WS3/A the MERGE will fail (no-checkout flag is
set). Although the appearence of could be handled by the server
automatically. But what about /WS3/A/B? Depending on the merge applied B is
still deleted or B is alive again. If B is alive again, what happens to the
checked-in version of B? Must it be set manually to the "right" version?
Would the complete subtree rooted at B appear again? (Suppose yes)

Regards,
Daniel

Received on Tuesday, 12 February 2002 10:10:35 UTC