Next message: jamsden@us.ibm.com: "Re: working resource DAV:merge-state property?"
Date: Fri, 14 Apr 2000 09:12:31 -0400 (EDT)
Message-Id: <200004141312.JAA15165@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: working resource DAV:merge-state property?
<geoff> 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 </geoff>
From: jamsden@us.ibm.com
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 is one of the more complex operations, and to say that
a server shouldn't be involved in it seems a bit strange
since many servers can (and do) help with the process.
This is particularly true for merging (versioned) collections. The
only operation is add and remove member, and the default merge
(i.e. accept all the adds and deletes) is only complicated when both
contributors tried to add a new binding with the same name. In the
common case where the merge is trivial, it seems sensible to let the
server propose this result with the DAV:final merge state, and in
ambiguous cases, the server could indicate a suggested merge
with DAV:intermediate merge state.
For other types of resources, the server might have no idea
what the merge would look like, and could just set DAV:initial
merge state.
Any server that performs this function will continue to do so ...
the only question is whether we will define an interoperable way
of letting the server convey this information back to a client.
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.
I agree that the response to the MERGE request could be used
to capture this information, but actually performing (or verifying
the correctness) of the merges takes time, making it very likely
that this information would need to be stored persistently until
all merges were completed and checked in. Storing this information
on the working resources themselves allows multiple clients to
be involved in the merge process, instead of just the client that
initiated the merge. It also has the benefit that the server can
detect errors like attempting to checkin a merge before updating
the contents.
Merging changes in two resources will always require user
intervention, even in the case of pure text and auto-merge without
collisions.
Yes, which is why the MERGE command leaves all "automatic" merges as
working resources, so that the user can verify the correctness
of the merge before checking it in. The benefit of the DAV:merge-state
property is that it lets the user know whether or not the server has
a proposed merge for that resource, or whether the client/user has to do it
from scratch (by investigating all the predecessors).
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.
I agree with all this, but I'm not sure what the relevance is for the
question of whether the server should have a mechanism for conveying
the initial state of the merged working resource to the client.
So I don't think a server should ever attempt to do anything except
checkout the merge target.
I agree that a server should never automatically perform a merge
without user confirmation. I strongly disagree that a server should
not help with the merge process ... in fact, I believe the more help
the server can provide with an initial proposal for the merge, the
better.
Cheers,
Geoff