W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Question on Checking (of Working Resource vs. VCR): is this r ight?

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 15 Jun 2001 08:51:59 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10350A68E@SUS-MA1IT01>
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


   (*) 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 :-).

Received on Friday, 15 June 2001 08:46:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC