- From: Tim Ellison <tim@ellison.name>
- Date: Sat, 06 Apr 2002 07:35:59 -0500
- To: ietf-dav-versioning@w3.org
[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