- From: Rick Rupp <rick.rupp@merant.com>
- Date: Thu, 21 Jun 2001 15:15:29 -0700
- To: ietf-dav-versioning@w3.org
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