- 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