- From: Alison Macmillan <alison.macmillan@oracle.com>
- Date: Fri, 20 Jun 2003 15:36:04 +0100
- To: ietf-dav-versioning@w3.org
A colleague & I have a question about the DAV:merge-preview report for a server capable of auto-merging version-controlled collections. The MERGE method itself can include a DAV:no-auto-merge element, which would prohibit the server from auto-merging a collection. As we understand it, the response to the MERGE method can change dependent on whether or not the server is permitted to auto-merge collections. The DAV:merge-preview report has no similar directive to allow / disallow auto-merging consequences. Given this, how should the report be evaluated? For example, is the intention that the report describe the changes that would be the result from a MERGE request which excludes a DAV:no-auto-merge (and a DAV:no-checkout) element? The following example illustrates how we understand merge to work for a server that supports: 1. Server workspaces. 2. Version-controlled collections 3. Auto-merging of version-controlled collections. Assume the following resources: Version Control Resources: ---------------------------- server/ws/fred/top where DAV:checked-in is server/v/1/ver/2 server/ws/fred/top/foo.c where DAV:checked-in is server/v/2/ver/1 server/ws/fred/top/bar.c where DAV:checked-in is server/v/3/ver/2 Version Histories: ------------------ server/vh/1 this is a for a collection resource server/vh/2 this is for a non-collection resource server/vh/3 this is for a non-collection resource Version resources: ------------------- The DAV:version-set of history server/vh/1 includes: server/v/1/ver/1 - has no bindings server/v/1/ver/2 - has bindings for server/vh/2 and server/vh/3 server/v/1/ver/3 - has bindings for server/vh/2 only. (server/v/1/ver/2 is not a predecessor of server/v/1/ver/3) The DAV:version-set of history server/vh/2 includes: server/v/2/ver/1 The DAV:version-set of history server/vh/3 includes: server/v/3/ver/1 server/v/3/ver/2 server/v/3/ver/3 (server/v/3/ver/2 is not a predecessor of server/v/3/ver/3) Activity; -------- server/act/fix1 where DAV:activity-version-set includes server/v/1/ver/3 and server/v/3/ver/3. Then issuing the following MERGE request: MERGE /ws/fred HTTP/1.1 Host: server Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8"?> <D:merge xmlns:D="DAV:"> <D:source> <D:href>http://server/act/fix1</D:href> </D:source> </D:merge> and assuming that the server automatically merges the version-controlled collection such that the checked-out resource, server/ws/fred/top, has only a version-controlled binding for server/vh/2, then we'd expect the MERGE response to include only the single DAV:response element: <D:response> <D:href>http://server/ws/fred/top</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> Resource server/ws/fred/top/bar.c is not in the response because the auto-merge of the parent collection removed the binding to the corresponding version-history. (Resource server/ws/fred/top/foo.c is not in the response because the activity does not identify it as a target) And likewise for server/ws/fred to contain the following resources: server/ws/fred/top with DAV:checked-out of server/v/1/ver/2 server/ws/fred/top/foo.c with DAV:checked-in of server/v/2/ver/1 However, if the DAV:no-auto-merge element was sent in the MERGE request then no merge of the collection would have been performed. The resource server/ws/fred/top/bar.c would have been recognized as a target, and the MERGE response would include DAV:response elements: <D:response> <D:href>http://server/ws/fred/top</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> <D:response> <D:href>http://server/ws/fred/top/bar.c</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> And likewise server/ws/fred would contain the following resources: server/ws/fred/top with DAV:checked-out of server/v/1/ver/2 server/ws/fred/top/foo.c with DAV:checked-in of server/v/2/ver/1 server/ws/fred/top/bar.c with DAV:checked-out of server/v/3/ver/2 Given this variation in the MERGE response, what should the response to a DAV:merge-preview report for the same merge request be? -- Alison.
Received on Friday, 20 June 2003 10:34:58 UTC