W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2003

DAV:merge-preview report

From: Alison Macmillan <alison.macmillan@oracle.com>
Date: Fri, 20 Jun 2003 15:36:04 +0100
Message-ID: <3EF31BD4.6DE0B1E7@oracle.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:44 GMT