Re: client workspaces, merging and forking

Alison Macmillan wrote:

> 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?
>

Sorry - please ignore this question. I guess the checked-out resource URL(s)
are returned in the DAV:merged-set response element, (and it also covers the
case of merging more than one merge version + target).

>
> 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.
>  -------------------------------------------------------------

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

Received on Friday, 24 August 2001 07:13:28 UTC