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

"Lisa Dusseault" <lisa@xythos.com> wrote:
> So does this mean that support for working resources
> effectively has a dependency on the UPDATE feature?
> It's at least consistent that both are included in
> the "basic client workspace" package.

Given that it is likely that users would want to make a version available
at a user-defined URL (i.e. as a version-controlled resource) then yes,
they would require UPDATE.
However, we have cases where we are creating versions that are only
accessed via their version URL and so UPDATE is not required there.

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

> Merge can only be done if there are a couple things that can
> be merged.  That's not always the case; nor is the server
> always capable of doing a merge.  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 ror 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.

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

> This dependency should at least be made clear.  We might also
> consider trying to remove the dependency, since one would think
> that in a non-forking server, a CHECKIN would 99% of the time
> be followed by a UPDATE to push the latest content to the VCR.
> Rolling those two actions into one request (unless specified
> otherwise) would save a round-trip, because the CHECKIN and
> UPDATE can't be pipelined if you have to wait for the successful
> response to the CHECKIN before knowing how to send the UPDATE.

These non-forking servers may use in-place-checkout to keep a
version-controlled resource up to date.

Tim

Received on Friday, 15 June 2001 07:12:47 UTC