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

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.

Section 9.4 does state that UPDATE or MERGE are required after a checkin
from a working resource, but this is misleading.  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.

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.

lisa


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, June 14, 2001 7:38 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Question on Checking (of Working Resource vs. VCR): is this
> r ight?
>
>
> It's not your user which needs to do the CHECKIN/UPDATE
> sequence, but rather your client (hopefully you will not
> be exposing your user to the working resource URL either).
>
> So your user just issues a "checkin" (or "freeze" or whatever
> you want them to call it) operation, and to implement it,
> your client issues a CHECKIN (which returns the URL of the
> newly created version), and then an UPDATE (which makes then
> makes the content and dead properties of the specified URL
> be those of the new version.
>
> A CHECKIN against a checked-in URL will just fail (you can
> only issue a CHECKIN against something that is checked-out,
> such as an in-place checked-out vcr, or a working resource.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: John Hall [mailto:johnhall@evergo.net]
> Sent: Thursday, June 14, 2001 6:56 PM
> To: 'Clemm, Geoff'; ietf-dav-versioning@w3.org
> Subject: RE: Question on Checking (of Working Resource vs. VCR): is this
> r ight?
>
>
> I have a non-forking server and I will not allow people to check out a
> prior version, which seems to be allowed in the spec.
>
> I'm willing to refuse to allow a CHECKIN on the working copy and require
> it be issued on the VCR.  But a CHECKIN that doesn't 'check the file in'
> violates the expectations of every user of every source control system
> I've ever seen.
>
>
>
> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
>
>
> A working resource can be created by checking out
> an arbitrary version, so in general, it is not
> associated with any VCR.
>
> So you do need to support either the update feature
> or the merge feature if you support the working resource feature (that
> is why the client-side workspace package contains the update feature.
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: John Hall [mailto:johnhall@evergo.net]
> Sent: Thursday, June 14, 2001 3:15 PM
> To: 'Clemm, Geoff'; ietf-dav-versioning@w3.org
> Subject: Question on Checking (of Working Resource vs. VCR): is this
> right?
>
>
>
> My user performs a CHECKOUT, PUT, and CHECKIN.  He wants the contents to
> change, and he wants a new version.
>
> I'm using working resources.
>
> To get this behavior, the user must:
> 1) CHECKOUT the VCR.
> 2) PUT on the working copy identified by the Location URL in the
> CHECKOUT response.
> 3) CHECKIN the VCR.
>
> It appears that if they do a CHECKIN on the working copy, they will not
> get what they expect.  9.4 indicates that they create a 'version' but
> that the VCR doesn't know about it.
>
> Since I don't support UPDATE or MERGE I seem to have two options.  Fail
> the CHECKIN on a working copy or treat it as a CHECKIN on the VCR
> silently.

Received on Friday, 15 June 2001 01:38:23 UTC