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

RE: Propagation of changes

From: Kirmse, Daniel <daniel.kirmse@sap.com>
Date: Wed, 30 Jan 2002 11:10:37 +0100
Message-ID: <59357A260E15D311B5A60008C75D3530068B4794@dbwdfx13.wdf.sap-ag.de>
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
o.k. so far, but take a look at some details:

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 0:
-------
no further developments took place on neither side -> MERGE does not have
anything to do here

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

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?
(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.)

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?

Regards,
Daniel

>-----Original Message-----
>From: gclemm@rational.com [mailto:gclemm@rational.com]
>Sent: Montag, 28. Januar 2002 20:01
>To: ietf-dav-versioning@w3.org
>Subject: RE: Propagation of changes
>
>
>To merge a baseline into a workspace, you use the
>MERGE request, i.e.
>
>MERGE /ws/B
><D:merge> <D:source> 
>  <D:href>/repo/bl/1573</D:href>
>  </D:source> </D:merge>
>
>Cheers,
>Geoff
>
>
>-----Original Message-----
>From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
>Sent: Monday, January 28, 2002 9:48 AM
>To: Ietf-Dav-Versioning (E-mail)
>Subject: Propagation of changes
>
>
>Hi,
>
>suppose I have two workspaces A and B. Both of them are under
>baseline-control. 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. 
>The development was going on. Changes were made. Files were added and
>deleted.
>
>Now I want to do an update of the consolidation refering to a 
>newer baseline
>of A.
>
>How could this be done?
>
>First I would use the compare-baseline report to get a diff of 
>the baseline
>A used for creation of B and the newer baseline of A. (Could I 
>compare a
>baseline of workspace B with a baseline of A [well, of course comparing
>baselines of the version-controlled configurations of B and A]).
>But how do I get the changes "merged" into workspace B?
>Is this in scope of DeltaV?
>
>Regards,
>Daniel
>
Received on Wednesday, 30 January 2002 05:11:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT