RE: client workspaces, merging and forking

I agree with Alison.  If the DAV:checked-in version of the VCR is
an ancestor of the checked-out resource, by definition the content
of the VCR has been "included" in the content of the checked-out
resource (that's the defined semantics of "ancestor").  This could
happen because:
- the UPDATE method was used to set the DAV:checked-in version to
be a predecessor of the current DAV:checked-in version
- the owner of the checked-out resource explicitly added the current
DAV:checked-in version to the DAV:predecessor-set of the checked-out
resource (assumedly, after merging the content of the DAV:checked-in
version into the content of the checked-out resource).

In either case, it should be legal for the checked-out resource to
be checked in, which is what the revised postcondition allows.  

Cheers,
Geoff

-----Original Message-----
From: Alison Macmillan [mailto:alison.macmillan@oracle.com]
Sent: Tuesday, September 04, 2001 8:13 AM
To: Tim Ellison
Cc: ietf-dav-versioning@w3.org
Subject: Re: client workspaces, merging and forking




Tim Ellison wrote:

> "Clemm, Geoff" <gclemm@rational.com> wrote:
> >    From: Alison Macmillan [mailto:alison.macmillan@oracle.com]
> >
> >    > [to checkin a working resource whose DAV:checked-out version does
> not
> >    > match the DAV:checked-in version of the DAV:auto-update VCR]
> >    > 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).
> >
> > Not by the current protocol, since the DAV:no-overwrite-by-auto-update
> > postcondition states:
> >
> >  If the DAV:auto-update property for the checked-out resource
> >  identifies a version-controlled resource, the DAV:checked-out property
> >  of the checked-out resource MUST identify the same version as the
> >  DAV:checked-in property of that version-controlled resource.
> >
> > We could relax that constraint to say:
> >
> >  If the DAV:auto-update property for the checked-out resource
> >  identifies a version-controlled resource, at least one of the
> >  versions identified by the DAV:predecessor-set property of the
> >  checked-out resource MUST identify a version that is either the same
> >  as or a descendant of the version identified by the DAV:checked-in
> >  property of that version-controlled resource.
> >
> > If there are no objections, I'll place this on the "editorial fix"
> > list for draft 17.
>
> I object to this -- it is certainly not an editorial fix.
>
> The purpose of this postcondition is to prevent the auto-update
overwriting
> changes made by other clients, by ensuring that the update is being
applied
> to the same state of the resource that was checked-out.  With this
proposed
> rewrite data can be lost unwittingly.
>

How are other client's changes overwritten? Doesn't the constraint on the
value
of DAV:predecessor-set indicate that the appropriate merge has happened?

R'gds,
Alison.

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

Received on Tuesday, 4 September 2001 09:17:15 UTC