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

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 17:37:27 UTC