RE: client workspaces, merging and forking

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

Regards,
Tim

Received on Tuesday, 4 September 2001 06:20:08 UTC