- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 15 Jun 2001 08:51:59 -0400
- To: ietf-dav-versioning@w3.org
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] "Lisa Dusseault" <lisa@xythos.com> wrote: > Section 9.4 does state that UPDATE or MERGE are required > after a checkin from a working resource, but this is > misleading. What it actually says is: "Note that checking in a working resource does not change the content or dead properties of any version-controlled resource, therefore an UPDATE or MERGE request must be used to update a version-controlled resource with the content and dead properties of a version created by checking in a working resource" So yes, to clarify, that "must be used" should be changed to "may be used" (i.e. if you don't want to update a version-controlled resource, then don't bother with an UPDATE or MERGE.) This sentence was intended to be parsed as "in order to update a version-controlled resource with the content and dead properties of a version created by checking in a working resource, an UPDATE or MERGE request must be used". This was an attempt (clearly unsuccessful :-) to preemptively address the question above. I'll try to reword this so that it is clearer. > Merge can only be done if there are a couple things that can > be merged. There is always at least one other version (the initial version). > That's not always the case; nor is the server > always capable of doing a merge. Note that if your server does not support branching, a MERGE will always just set the content and dead properties to whatever version is later ... no client or server defined content modification is required. > Imagine I check out an > image in my repository, I get a working-resource URL, and I > PUT the new image to the working-resource. Now you can see > that UPDATE is absolutely required or the version-controlled > resource to ever have its contents and dead properties change. The MERGE is merging version history, not resource content(*). To merge means to update this version-controlled resource with the latest (in the version history) version given two versions to choose from, or complain if one version is not the predecessor of the other. That is, if the versions are on different branches then it is ambiguous as to which version represents the 'latest' state of the resource and the merge must fail. Obviously there is more to it than that, and the definitive description is given in the document. Yes. (*) the spec does give a server the right to merge content if it is capable of doing so, and the server must give an indication of what it has done so that it can be verified. This is only going to be available on super-advanced servers (with initals CC <g>) Actually we only do the simple automatable merges (i.e. merging two directory versions). For content merges, we leave that to the user (although we do provide a super-duper n-way merge GUI to help out :-). Cheers, Geoff
Received on Friday, 15 June 2001 08:46:34 UTC