W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Re: client workspaces, merging and forking

From: Alison Macmillan <alison.macmillan@oracle.com>
Date: Fri, 24 Aug 2001 18:44:15 +0100
Message-ID: <3B86926F.1472CF06@oracle.com>
To: ietf-dav-versioning@w3.org

"Clemm, Geoff" wrote:

> Alison Macmillan wrote:
> > 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)?
> Yes, it probably would be worth allowing the merge target to be
> a working resource.  I'll put that on the "fixes to draft 17" list.
> > 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.
> You have two choices:
> - Do what you would do on a non-forking server, i.e. checkout the new
> version to get a new working resource, merge the contents of your old
> working resource into that new working resource, delete the old
> working resource, and then checkin the new working resource (and if
> someone else has checked in a new version since your checkout,
> repeat the process).

Or, could you also just merge from the DAV:checked-in version of the VCR to
the working resource, and then check in the working resource? (Now that a
working resource can be a merge target).

 The statements and opinions expressed here are my own
 and do not necessarily represent those of Oracle Corporation.
Received on Friday, 24 August 2001 13:50:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC