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

They asked how a server could allow multiple checkouts of the same
version.

I mistyped, the DELETION was meant to come from user3.


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Rick Rupp
> Sent: Thursday, June 21, 2001 3:15 PM
> To: ietf-dav-versioning@w3.org
> Subject: 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 19:16:37 UTC