RE: Semantic of MOVE between working collections

   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 UTC