RE: A simpler response ... RE: Working Resource Issues ...

I am assuming this is a case where the server does not support forking. Why 
did the second and third checkout succeed? /foo.txt should have changed 
into a checked out resource after the first checkout.

Could you explain how and why User2 deleted the invisible resource for User3?

At 02:37 PM 6/21/01 -0700, John Hall wrote:
>Assume the server wants to implement multiple concurrent checkouts.
>
>User1: CHECKOUT /foo.txt <invisible>
>Response:
>OK
>Location: /invisible?file_id=4301&ver_id=7549
>
>User2: CHECKOUT /foo.txt <invisible>
>Response:
>OK
>Location: /invisible?file_id=4301&ver_id=8051
>
>User3: CHECKOUT /foo.txt <invisible>
>Response:
>OK
>Location: /invisible?file_id=4301&ver_id=9051
>
>User1: PUT /invisible?file_id=4301&ver_id=7549
>
>User2: DELETE /invisible?file_id=4301&ver_id=9051
>
>User2: PUT /invisible?file_id=4301&ver_id=8051
>
>User2: CHECKIN /invisible?file_id=4301&ver_id=8051
>Response OK // I win!
>
>User1: CHECKIN /invisible?file_id=4301&ver_id=7549
>Response:
>Conflict
><cannot-modify-version-controlled-content/>
>
>========================================================
>At that point you have a number of places you can go.  The simplest for
>User1 is to vow to use a lock next time, but in this case (to be
>polite):
>
>GET /foo.txt
>Diff _local_copy_with_working_copy
>Edit _local_copy_with_working_copy
>PUT /invisible?file_id=4301&ver_id=7549
>CHECKOUT /foo.txt
>CHECKIN /invisible?file_id=4301&ver_id=7549
>========= OR if not polite ==============
>CHECKOUT /foo.txt
>CHECKIN /invisible?file_id=4301&ver_id=7549
>
>----------------------------
>Is that clear how multiple checkouts of the same version could work?
>Basically, you have the same mechanism you had with your
>WORKING-RESOURCE feature to allow multiple checkouts (the Location
>header).  Now, ALLOWING mutliple checkouts yeilds the problem of
>conflict / merge resolution.  The simpliest policy is to make the user
>resolve it.
>
>
>
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
> > Sent: Thursday, June 21, 2001 1:58 PM
> > To: 'DeltaV (E-mail)'
> > Subject: RE: A simpler response ... RE: Working Resource Issues ...
> >
> >
> > I don't see where you addressed Stefan's question.
> > Allowing multiple checkouts of the same version is
> > a key use case.  Limiting this to a single checkout
> > is supported in an interoperable way by allowing the
> > server to set the DAV:checkout-fork property to DAV:forbidden.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: John Hall [mailto:johnhall@evergo.net]
> > Sent: Thursday, June 21, 2001 12:19 PM
> > To: 'Stefan Eissing'; 'DeltaV (E-mail)'
> > Subject: A simpler response ... RE: Working Resource Issues ...
> >
> >
> > There is only one 'in-place-checkout' now, so perhaps we
> > should insist that any "invisible" in-place-checkout's should
> > be unique.  Therefore, the only difference is the visibility
> > of the work in progress.
> >
> > The only reason I made them different URL's is to preserve
> > the semantics where if you PUT on a resource and then GET you
> > are supposed to GET what you just PUT.  Therefore, for the
> > PUT's to be invisible it must be a different URL.
> >
> > This isn't much different than lock resource, GET, modifing
> > the local copy, PUT, unlock.
> >
> >
> >
> > > -----Original Message-----
> > > From: ietf-dav-versioning-request@w3.org
> > > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of
> > > Stefan Eissing
> > > Sent: Thursday, June 21, 2001 7:20 AM
> > > To: John Hall; 'DeltaV (E-mail)'
> > > Subject: AW: Working Resource Issues ...
> > >
> > >
> > > John,
> > >
> > > if I understand your proposal correctly, one user could not
> > > have two working resources of the same version resource,
> > > since there is only a single URL to access it. Correct?
> > >
> > > Wouldn't that be a major drawback for a versioning repository?
> > >
> > > Stefan
> > >
> > > > Von: ietf-dav-versioning-request@w3.org
> > > > [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von
> > John Hall
> > > >
> > > > "If you remain calm while everyone else is panicking, then you
> > > > probably don't understand the situation." -- old Naval saying.
> > > >
> > > > It appears that some of the long discussion on this topic has been
> > > > prompted by completely different understandings of what a
> > > > "WORKING-RESOURCE" is and should mean.
> > > >
> > > > I just thought it was a bit-bucket where the user could store his
> > > > state until he was finished.  Check out VCR, get bit
> > bucket, modify
> > > > bit bucket, Check In.  The critical difference between
> > > > Check-Out-In-Place and Check-Out-Working-Version was the
> > > visibility of
> > > > the bit bucket to other users.  In-Place, they can see it.
> > > > Working-Version, they can't.
> > > >
> > > > I've also mentioned that I'm concerned with 3rd party
> > > emulation.  The
> > > > 3rd party has a 'working version', and that is exactly how they
> > > > implemented the concept.
> > > >
> > > > That IS NOT what this spec defines.  In the post
> > conditions for 9.3
> > > > create-working-resource-from-checked-in-version the spec
> > > states that
> > > > "... the version-controlled resource remains checked-in."
> > > >
> > > > That is why you have seen two operations when I've only
> > > seen one, and
> > > > need an UPDATE or MERGE.  Meanwhile, I'm going "of COURSE
> > > the VCR is
> > > > checked out.  I got a successful return on my CHECKOUT
> > > didn't I?"  I
> > > > think you should create a new verb (MKWORKING), personally.
> > > >
> > > > So how about leaving the WORKING-RESOURCE definition as-is
> > > and modify
> > > > the CHECKOUT-IN-PLACE feature to make invisibility to
> > other users a
> > > > (REQUIRED) option?  I think you will have to finesse a
> > much smaller
> > > > number of issues if you do that.  Since it is required,
> > it doesn't
> > > > raise the issue of client interoperability.  It is new
> > > functionality;
> > > > you can't do what I need to do with the spec defined as
> > is.  And by
> > > > moving it down there you don't confuse the complex
> > 'package' issues
> > > > Geoff raised.  You put it in the basic package, and you
> > don't have
> > > > clients trying to figure out why they have WORKING-RESOURCE
> > > provided
> > > > but not UPDATE or MERGE.
> > > >
> > > > 4.1.3  DAV:checkout-invisible
> > > >
> > > > Normally, edits made on a resource while checked out are
> > visible to
> > > > other users.  If checkout-invisible is specified, however,
> > > other users
> > > > will only see the last checked-in version.  A client is
> > > encouraged to
> > > > see this feature as "lite" version of WORKING-RESOURCE
> > which leaves
> > > > the VCR in the checked-out state.
> > > >
> > > > 4.2 CHECKOUT Marshalling:
> > > >
> > > > If the element checkout-invisible is present, the response MUST
> > > > include a Location header.
> > > >
> > > > 4.6: Additional PUT / PROPPATCH semantics.
> > > >
> > > > If a Location header was returned with the CHECKOUT, the
> > > URL specified
> > > > in the Location header MUST be used for PUT and PROPPATCH
> > requests.
> > > > Otherwise, the server will return
> > > > cannot-modify-version-controlled-content.
> > > >
> > > > 4.7: Additional DELETE semantics.
> > > >
> > > > A delete on the URL returned by a CHECKOUT Location header
> > > will undo
> > > > the CHECKOUT which created it.
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >

Received on Thursday, 21 June 2001 18:16:59 UTC