RE: merge-preview Report, MERGE and UPDATE responses

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 Thursday, 27 September 2001 14:10:00 UTC