Next message: by way of : "OPTIONS method"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568C0.005FF092.00@d54mta03.raleigh.ibm.com>
Date: Thu, 13 Apr 2000 13:27:51 -0400
Subject: Re: working resource DAV:merge-state property?
My immediate reaction is that this is something the server shouldn't be
involved in. Merge on the server should only register the merge predecessor
and perhaps checkout the target. Merging composite resources like
collections, activities, workspaces, etc. should return a conflict list,
but otherwise update the target workspace with revisions that are not in
conflict. The returned report should also include what was done with the
workspace, not just the conflicts.
Merging changes in two resources will always require user intervention,
even in the case of pure text and auto-merge without collisions. A user is
well advised to examine the merge transcript for changes that need to be
propigated into the target, even though they did not create a conflict.
This often results when one developer makes a change to all components of
some structured document while another developer adds a new component using
the old structure. An auto-merge won't detect a conflict, and the new
component won't get the required updates. In source code, often the
compiler won't find this problem either, and you don't discover the issue
until testing. This often happens in case statements or newly added
methods.
So I don't think a server should ever attempt to do anything except
checkout the merge target.
|------------------------+------------------------>
| | "Geoffrey M. Clemm" |
| | <geoffrey.clemm@ratio|
| | nal.com> |
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 04/13/2000 01:09 PM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| Subject: |
| working resource |
| DAV:merge-state |
| property? |
>------------------------|
With the MERGE method, a new working resource is created with multiple
predecessors. In some cases, the server will give the new working
resource an empty body; in other cases, the server will support an
automatic merge capability and can populate the working resource with
some initial text; and in other cases the initial text is suitable for
checking-in, after review by the user.
It is probably useful/important for the server to indicate
which of these states the working resource is in, e.g.
DAV:initial; DAV:intermediate; DAV:final
Comments?
Cheers,
Geoff