Re: DAV:merge-preview report

This was deliberately left up to the server.  Since the results
of the auto-merge is up to the server, the exact result will be
server-dependent anyway.  Since commonly a client will want auto-merge
to be performed for collections, it didn't seem worth including a
parameter that most clients wouldn't use.

Cheers,
Geoff



Alison wrote on 06/20/2003 10:36:04 AM:

> 
> 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 17:22:27 UTC