Re: merge-preview Report, MERGE and UPDATE responses

This rationale sounds reasonable to me.

"Clemm, Geoff" wrote:

> I think it is useful to keep the DAV:merge-preview semantics
> the way they currently are.  If a client wants to guide the merge
> process, they would use the DAV:merge-preview report, and take
> advantage of the detailed information (such as common ancestor)
> provided there.  The MERGE method is there for clients that just
> want servers to do all the work.  If a client has used the MERGE
> method, and then wants to give the user some more help with a particular
> merge, it would ask for the DAV:merge-preview report for that
> particular merge.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Roy Seto [mailto:Roy.Seto@oracle.com]
> Sent: Thursday, September 27, 2001 9:22 AM
> To: ietf-dav-versioning@w3.org
> Subject: DAV:merge-preview Report, MERGE and UPDATE responses
>
> The DAV:merge-preview Report's response used to look like
> the responses of MERGE and UPDATE, but then DAV:ignore-set
> was dropped from MERGE and UPDATE, and MERGE and UPDATE's
> responses were brought in line with Multi-Status format
> following Tim Ellison's suggestion on August 21:
>
> http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001JulSep/0240.html
>
> Does it make sense to bring the DAV:merge-preview Report
> request and response format in line with the current format
> for MERGE and UPDATE?
>
> Also, as of draft-18, DAV:merge-preview Report identifies
> the common ancestor version for merge targets that need
> logical content merging by clients, but MERGE does not
> (though of course of client can still request a
> DAV:version-tree Report and compute the common ancestor
> itself). Does it make sense to introduce a mechanism (such
> as a property) for the server to identify common ancestor
> versions after a MERGE?
>
> Thanks,
> Roy

Received on Wednesday, 3 October 2001 11:02:13 UTC