RE: Propagation of changes

   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]

   common base:
   ------------
   suppose I have two workspaces A and B. Both of them are under
   baseline-control (with auto-version).  Furthermore I work with
   working resources and activities and version-controlled collections
   (to track namespace operations).  Further Suppose workspace A
   contains my current development and workspace B is a consolidation
   place. Workspace B was created with reference to a baseline of A.
   I have a VCR a located at workspace A and a VCR b located at
   workspace B both sharing a version history VH-AB.  At time of
   creation of workspace B from a baseline of workspace A. VCR a and
   VCR b had checked-in version V1 of VH-AB.

   case 1:
   -------
   VCR a has a checked-in version V-A2 (successor/descendant of V1).
   No changes made to VCR b, so b still has checked-in version V1.

   Now there is a MERGE. /repo/bl/1573 is the new baseline of A

   MERGE /ws/B
   <D:merge>
     <D:source> 
       <D:href>/repo/bl/1573</D:href>
     </D:source>
   </D:merge>

   so merge takes version V-A2 (merge source) and merges it to VCR b (merge
   target) because V-A2 is a descendant of checked-in version V1 of VCR b a
   auto-merge could be done setting checked-in version of VCR b to V-A2.
   Right?
   (This would suit my needs. Works as I expect it to do.)

Yes.  We don't use the term "auto-merge" here though, since we've been
using auto-merge to mean "neither version is a descendent of the other,
and the server has automatically done a merge into the checked out
target, that is to be reviewed by the client" (i.e. your case 3 below,
except that the server is being helpful).

   case 2:
   -------
   VCR b has a checked-in version V-B2 (successor/descendant of V1).
   No changes made to VCR A, so a still has checked-in version V1.

   Now there is a MERGE. /repo/bl/1573 is the baseline of A

   MERGE /ws/B
   <D:merge>
     <D:source> 
       <D:href>/repo/bl/1573</D:href>
     </D:source>
   </D:merge>

   so merge takes version V1 (merge source) and merges it to VCR b (merge
   target) because V1 is an anchestor of checked-in version V-B2 of VCR b a
   auto-merge could be done setting checked-in version of VCR b to V1.
   Right?

No, if the merge souce is an ancestor of the merge target, the merge
target is left unchanged.

   (This is not quite what I would expect/need. A change of the target would
be
   lost without further notice. I'd rather the server would fail this here
to
   let the user take the decision what version to keep for VCR b.)

The semantics are the one need, although there is no failure.
The merge target is a descendent of the merge source, which by the
semantics of line of descent, means that result of the merge leaves
the target unchanged.

   case 3:
   -------
   VCR a has checked-in version V-A2 (successor of V1). VCR b has checked-in
   version V-B2 (succesor of V1).

   Now there is a MERGE. /repo/bl/1573 is the baseline of A

   MERGE /ws/B
   <D:merge>
     <D:source> 
       <D:href>/repo/bl/1573</D:href>
     </D:source>
   </D:merge>

   so merge takes version V-A2 (merge source) and merges it to VCR b (merge
   target) because V-A2 is no anchestor or descandant of checked-in version
   V-B2 of VCR b a auto-merge could not be done. The request fails. User has
to
   do a manual merge on its own.
   Right?

The request doesn't "fail", it succeeds, but VCR b is left checked-out,
with a DAV:merge-set identifying version V-A2 (or if the server
is auto-merging, in the DAV:auto-merge-set).  The client must merge the
content of V-A2 into VCR b (or confirm that the server has correctly
auto-merged the contents of V-A2 into VCR b), and move the reference to
V-A2 from the DAV:merge-set to the DAV:predecessor-set of VCR b,
before it can check in VCR b.

Cheers,
Geoff

Received on Wednesday, 30 January 2002 08:27:35 UTC