client workspaces, merging and forking

I've been trying to understand how the working resource feature works
with merging and forking, and I've got a few questions:

1. For merging & client workspaces, should the DAV:checked-out-for-merge
merge postcondition cover the case that the DAV:checkout element
included a DAV:apply-to-version? In particular, should it say that a
Location: header must be in the response, and that this header contains
the URL of the working resource created by the checkout?

2. A merge target is a version-controlled resource. Was it unnecessary
to allow a merge target to be either a version-controlled resource or a
checked-out resource (e.g. a working resource)?

3. How does the working resource feature work for a forking server? For
example, suppose that http://repo.webdav.org/wr/1 and
http://repo.webdav.org/wr/2 identify two working resources that are
created by requesting a checkout on a version controlled resource,
http://repo.webdav.org/foo.html, and including a DAV:apply-to-version in
the request. The DAV:checked-in property of the vcr is
http://repo.webdav.org/his/1/ver/V5. This is also the value of the
DAV:checked-out property of each of the working resources. Each working
resource has it's DAV:auto-update property set to the vcr URL. Now
suppose that the first working resource (http://repo.webdav.org/wr/1) is
checked in, creating version http://repo.webdav.org/his/1/ver/V6, and
that postcondition DAV:auto-update applies - the DAV:checked-in property
of the vcr is now set to http://repo.webdav.org/his/1/ver/V6. Does this
then mean that it is impossible to ever check in the second working
resource, http://repo.webdav.org/wr/2, as it's DAV:checked-out property
points to http://repo.webdav.org/his/1/ver/V5, and precondition
DAV:no-overwrite-by-auto-update prevents the checkin? The
DAV:auto-update property is protected, and so can't be changed by a
client PROPPATCH.

4. Looks like there's a typo in draft 16, section 9.4 - the CHECKIN
'forking' preconditions reference DAV:checkout-... conditions.

Thanks,
Alison Macmillan

--
 -------------------------------------------------------------
 The statements and opinions expressed here are my own
 and do not necessarily represent those of Oracle Corporation.
 -------------------------------------------------------------

Received on Friday, 24 August 2001 06:10:32 UTC