RE: Semantic of MOVE between working collections

[freed from spam trap -rrs]

Date: Fri, 5 Apr 2002 16:27:32 -0500 (EST)
Message-ID: <FDEHJMOEIDFPFLBKEICGEEEICGAA.tim@ellison.name>
From: "Tim Ellison" <tim@ellison.name>
To: <ietf-dav-versioning@w3.org>

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Konstantin
> Knizhnik
> Sent: 05 April 2002 10:50
> To: 'ietf-dav-versioning@w3.org'
> Subject: Semantic of MOVE between working collections
>
>
> Let's say we have VCR /somedir/foo.txt corresponding to version history
> /repo/vh/vh1. Now consider the following sequence of requests:
>
> 1. Checkout source collection (create working collection)
> Request:
>         CHECKOUT <apply-to-version> /somedir
> Response:
>          Location: /repo/wr/wr1
>
> 2. Checkout target collection (create working collection)
> Request:
>         CHECKOUT <apply-to-version> /anotherdir
> Response:
>          Location: /repo/wr/wr2
>
> 3. Move resource from source to target collections
> Request:
>         MOVE /repo/wr/wr1/foo.txt  /repo/wr/wr2/foo.txt
>
> 4. Execute locate-by-history report for version history of this resource
> Request:
>         REPORT DAV:locate-by-history  /repo/vh/vh1
> Response:
>          ???

The DAV:locate-by-history report is applied to a collection to find the
member that is a version-controlled resource for the given version history.

In this scenario, you have two working collections, whose members are
version histories (not version-controlled resources) so the report would be
no use there.

Since the MOVE operation was on the working collections, it had no effect on
the checked-in version-controlled collections for the source and target, so
you could use REPORT on the source with /repo/vh/vh1 to find
/somedir/foo.txt

> Which HREF will be returned by last locate-by-history report?
> /somedir/foo.txt or /anotherdir/foo.txt or /repo/wr/wr2/foo.txt?
>
>
> If answer is /somedir/foo.txt then behavior seems to be strange for
> the client which performed this move - he had moved the file but find
> it under the old path. But it is no (or minor) problems with
> implementing this
> behavior.
>
> If answer is /anotherdir/foo.txt, then the question is whether all
> other clients will also receive the same answer for the same
> DAV:locate-by-history request before /anotherdir collection is
> checked-in? If so, it seems to violate one of the most significant
> requirements to version control system - that uncommitted changes made
> by some user will not be visible to all other clients.
> Looks like the only consistent behavior is that the client which has
> checked out /somedir and /anotherdir collection will see foo.txt under
> path /repo/wr/wr2/foo.txt while all other clients will see it under
> path /somedir/foo.txt until first client checkout these collections.
> But how it is possible to implement it? To be able to implement such
> behavior I need to somehow verify that user which have done CHECKOUT
> of /anotherdir (or in other words owner of wr2 working resource)
> is the same as user requested locate-by-history report. So to be able
> to implement this behavior we need authentication and notion of
> resource owner. But both are not part neither of WebDAV neither of
> DeltaV specifications (DAV:owner is declared in WebDAV ACL draft, but
> this standard in turn knows nothing about versioning). In other words,
> semantic of MOVE can not be expressed in terms of the specification!
>
> If answer is /repo/wr/wr2/foo.txt then in addition to questions and
> problems described in previous section, there is one more question -
> how it is possible in this case for this client to know path of
> foo.txt resource? Lets say that client forgot that foo.txt was
> members of /somedir collection and later was moved to /anotherdir.
> So the only thing client knows is version of the resource. Can client
> somehow request server about the parent of this resource?
>
> --
> Best regards,
>  Konstantin                          mailto:KKnizhnik@togetherlab.com

Regards,
Tim

Received on Saturday, 6 April 2002 07:37:48 UTC