W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2002

RE: Semantic of MOVE between working collections

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 5 Apr 2002 23:58:41 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1066908C1@SUS-MA1IT01>
To: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
   From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]

   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:
	    ???

   Which HREF will be returned by last locate-by-history report?
   /somedir/foo.txt or /anotherdir/foo.txt or /repo/wr/wr2/foo.txt?

Only /somedir/foo.txt.  /anotherdir/foo.txt will not exist until
/repo/wr/wr2 is checked in.  /repo/wr/wr2/foo.txt is not
a version-controlled resource, and DAV:locate-by-history only
locates version-controlled resources.

   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.

It shouldn't be strange for the client that performed the move.
Changes made to a working resource are not visible until that working
resource is checked in.

   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? 

The answer is not /anotherdir/foo.txt, and the response to a successful
locate-by-history request will be independent of what client makes it.

   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.

Yes, that would be bad.

   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.

No, the only consistent behavior is to satisfy the semantics defined
by the report (:-).  /repo/wr/wr2/foo.txt is not a version-controlled
resource, and therefore will never be returned by a locate-by-history
report.

Before /repo/wr/wr2 is checked in, the answer will be
/somedir/foo.txt.  After the two working collections are checked in,
the answer will be /otherdir/foo.txt.  Simple and consistent.

Cheers,
Geoff
Received on Friday, 5 April 2002 23:59:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT