FW: Selective propagation of changes

this one was wrongly replied, sorry Geoff

-----Original Message-----
From: Kirmse, Daniel 
Sent: Mittwoch, 13. Februar 2002 16:16
To: 'Clemm, Geoff'
Subject: RE: Selective propagation of changes




> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Mittwoch, 13. Februar 2002 15:29
> To: Ietf-Dav-Versioning (E-mail)
> Subject: RE: Selective propagation of changes
> 
> 
>    From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
> 
>    suppose in workspace WS1 there is a collection C containing two
>    Files F1, F2. F1 was created with activity A1 and F2 was created
>    with activity A2.  Subsequent changes to F1 were made with activity
>    A3 and for F2 activity A4 was used for this purpose.
> 
>    further suppose in WS2 there allready is a collection C w/o any
>    members (created with earlier MERGES).
> 
>    For some reasons I only want to propagate F2 (cause F1 is not ready
>    yet or secret or ...). The MERGE of A4 into WS2 would fail cause F2
>    does not exist.
> 
> Actually, it would succeed, but would have no effect on WS2.
> 
>    So first I have to MERGE activity A2. Doing this I MERGE a version
>    of /WS1/C into WS2 that contains a binding to F1. Due to that a vcr
>    for F1 has to be created. Thats definitely not what I want to have.
> 
>    So merging the Activity A2 is not an good idea. Only with activity
>    A2 there was just the creation of F2. And I just want to propagate
>    this creation. But I get other stuff as well. Is this a) right b)
>    "sensible"
> 
> OK, this is a good news/bad news kind of thing.  The good news (a) you
> are right and (b) you are sensible.  In addition, DeltaV provides the
> object you need for this (an activity).  The bad news is that there is
> no standard method defined by DeltaV for this, so you'll need a custom
> method if you want to have your server provide this service.
> 
> I would suggest the method name DELTA, and if you want to be fully
> general, it would take a list of "add" activities (i.e. those whose
> deltas you want to add) and a list of "subtract" activities
> (i.e. those deltas you want to remove).
> 
> Unlike MERGE (which only performs a checkout if the versions are
> on different lines of descent), DELTA will always checkout the
> target, and will always have the server compute the results of
> adding/deleting the specified deltas (i.e. that's the whole point
> of the DELTA request).
> 
> Note that a MERGE of an activity (which effectively merges an 
> entire line of descent) is very different from a DELTA of an
> activity (which only applies the differences captured by an activity).
> 

That sounds good. Only it would be propriatry for the server that invents
this. What do you think, is this a feature that is worth of being part of
the DeltaV? Was this in discussion yet and skip due to some reason?
I don't like the propriatry thing that much. But if its not worth of being
part of the standard, so it is and then its proprietary.

Regards,
Daniel

Received on Wednesday, 13 February 2002 10:32:43 UTC