VCR Fork and GET

Hi,

another question:

Suppose a VCR with the history shown below. As DeltaV states in "3.2.1
DAV:checked-in (protected)" a checked in VCR gots a property "<!ELEMENT
checked-in" (href)>" assigned to it. In the example it would be the URL of
version V3 of the VCR that has to be stored with this property.


         /foo.html (version-controlled resource)

          +----+    
          | S2 |    
          +----+    
       Checked-In=V2


         /his/73 (version history for /foo.html)

         +----+     
         | S1 | V1  
         +----+     
            |       
            |       
         +----+     
         | S2 | V2  
         +----+     


Further suppose a user checks out the VCR. With that the URL stored in the
"Checked-in" property has to be stored in a "Checked-out" property of that
very VCR. The "Checked-in" property vanishes to nothing. No damage done so
far.


            ===checkout user 1==>


         /foo.html (version-controlled resource)

          +----+    |    +----+    
          | S2 |    |    | S2 |    
          +----+    |    +----+    
       Checked-In=V2|Checked-Out=V2


         /his/73 (version history for /foo.html)

         +----+     |   +----+     
         | S1 | V1  |   | S1 | V1  
         +----+     |   +----+     
            |       |      |       
            |       |      |       
         +----+     |   +----+     
         | S2 | V2  |   | S2 | V2  
         +----+     |   +----+     
                    |              

Now suppose another user that wants to check out the very same VCR. Checkout
fork is allowed and/or fork-ok is sent with the request.

Now (my) trouble starts:

1. There is no "checked-in" property that could give me the version to check
out. One Precondition for check out is:

		(DAV:must-be-checked-in): If a version-controlled resource
is being checked out, it MUST have a DAV:checked-in property.
Is this a condradiction? What is the solution?

O.k., suppose the checkout of both of the users was successfull

       ===checkout user 1==> ===checkout user 2==>


         /foo.html (version-controlled resource)

          +----+    |    +----+    |    +----+
          | S2 |    |    | S2 |    |    | S2 |
          +----+    |    +----+    |    +----+
       Checked-In=V2|Checked-Out=V2|Checked-Out=V2


         /his/73 (version history for /foo.html)

         +----+     |   +----+     |    +----+
         | S1 | V1  |   | S1 | V1  |    | S1 |
         +----+     |   +----+     |    +----+
            |       |      |       |       |________
            |       |      |       |       |        |
         +----+     |   +----+     |    +----+   +----+
         | S2 | V2  |   | S2 | V2  |    | S2 |   | S3 |
         +----+     |   +----+     |    +----+   +----+
                    |              |       
Now there are two checked out versions of the VCR. But there is only one
Checked-Out property.

2. Does a VCR got a checked-out property for every checked out version?  If
not, how a fork is handled correctly?

3. After checkin of both versions without merging (fork-ok or checkin-fork
not forbidden) there are two checked in versions of the VCR now. There are
two checked-in properties now  to?

As far as I know a not versioning aware client sends a GET request to the
VCR itself to get the content of it. Asuming a single line of descent the
content to deliver simply is the most current checked in version. (Same
applies to a server that implements only basic versioning features (i.e. no
version histoty and with that no version resource URI)).

4.If there is no single line of descent, the server has to provide a
reasonable reply. What would it be?


Regards,
Daniel

Received on Wednesday, 12 December 2001 05:01:13 UTC