RE: Clarification of DAV:update-merge-set when rerunning MERGE

   From: Roy Seto [mailto:Roy.Seto@oracle.com]

   I'm looking at the behavior of the MERGE method when it is
   rerun. I'd like clarification of the DAV:update-merge-set
   postcondition in Section 11.2 for this scenario. 

   Specifically, if a merge target was already checked out
   before the second or later MERGE, and its DAV:merge-set or
   DAV:auto-merge-set already includes the merge source, does
   the merge target appear in a DAV:response XML element in the
   response body? 

Yes, this is required by the last sentence of the DAV:update-merge-set
postcondition.

   I feel this is ambiguous in draft-18. The
   DAV:update-merge-set postcondition does apply to this merge
   target, because it was already checked out before the MERGE,
   and its DAV:checked-out version is not a descendant of the
   merge source (assuming a client has not moved the merge
   source from DAV:merge-set to DAV:predecessor-set between the
   MERGE requests). However, the state of the merge target does
   not actually change in the second MERGE request, since
   adding a source to a DAV:merge-set which already contains it
   doesn't change the DAV:merge-set property.

The last sentence of DAV:update-merge-set applies to any
target that matches this postcondition, i.e.:

 If the merge target was checked out by the MERGE (or was already
 checked out before the MERGE), and if the DAV:checked-out version of
 the merge target is not a descendant of the merge source ...

There is no dependency on whether or not the the merge source
is already in the DAV:merge-set or DAV:auto-merge-set.
If this is not clear, I could move the "must be in a DAV:response"
sentence up into the first sentence of this precondition, if you
think that would be clearer.

[restart example omitted]

   Alternative options I considered for supporting restart:

    - The client could do a PROPFIND Depth:infinity
      and look for resources which have nonempty 
      DAV:merge-set or DAV:auto-merge-set properties,
      but it seems difficult to make this efficient.
      It also requires the client to detect the restart
      case and implement it with a different code path.

Well, a client has to do this anyway, if the user doesn't
remember what MERGE they performed.  But I agree that this
would be a challenge to make efficient.  One approach is
to play a little fast'n'loose with the PROPFIND semantics,
and only have the PROPFIND return results with non-empty
DAV:(auto-)merge-set properties, and just use an index
on those properties to optimize the speed of the PROPFIND.

    - The client could do a DASL query to optimize
      the PROPFIND above if DASL were standardized.

Yeah, that would be nice (:-).

And of course, option 3 is to just use the DAV:merge-preview
report to get the info you need.

   --

   I have a similar question about the behavior of the
   DAV:merge-preview REPORT after the corresponding MERGE has
   already been done. If a merge target requires a merge, and
   its DAV:merge-set or DAV:auto-merge-set already includes the
   merge source, does the response body include it in a
   DAV:conflict-preview element? (For reasons similar to the
   DAV:update-merge-set case, I prefer that it must.)

The merge-preview element contains all resources that "need
to be merged".  Whether or not something needs to be merged
is not changed by that version already being in the
DAV:merge-set.  So DAV:merge-preview definitely works the
way you want (and was intended to do so).

Cheers,
Geoff

Received on Saturday, 15 September 2001 12:00:05 UTC