RE: Re[2]: Semantic of MOVE between working collections

   From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]

   So, PROPFIND with DEPTH=1 for working collection will return set of
   version histories, not VCR, right?

Right.

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

   Ok, there are some other things not clear to me in the example above.
   So what happens after
      MOVE /repo/wr/wr1/foo.txt  /repo/wr/wr2/foo.txt
   (assuming that foo.txt belongs to the version history /repo/vh/vh1)
   Binding to MOVE /repo/vh/vh1 is removed from  /repo/wr/wr1
   and is added to /repo/wr/wr2, isn't it?

Yes.

   Then, let's say, we checkin /repo/wr/wr1. The VCR foo.txt should be
   removed, right?

Yes (from /somedir).

   Then we checkin /repo/wr/wr2. The VCR with name foo.txt referring to
   the history /repo/vh/vh1 should be created, right?

Yes (in /otherdir).

   But which version this VCR should select in its DAV:checked-in property?

It's up to the server.

   The obvious answer - the same as was selected by foo.txt VCR
   before MOVE. But working collection contains only bindings to versions
   histories, so there is no way to store information about checked-in
   version.

That's correct.  One way a server could know to do the expected thing
would be if both working collections were in the same activity, and
the user checked in the activity as a whole.  In this case, the
server could remember information about VCR checked-in versions,
and use those as the versions when creating a new VCR.

Note that this is only an issue with working collections.  With
checked-out version-controlled collections, the MOVE actually moves
the VCR, so the DAV:checked-in value just goes along for the ride.

   And one more obscure item for me: if we perform MOVE from versioned
   collection to not-versioned collection. Is it allowed operation?

Depends on the server.  I would expect that most servers would not
support this, but they certainly could do so.

   What is the result of such operation? For example:

      MOVE /repo/wr/wr1/foo.txt /new.txt

   Should new.txt be a new resource (with new resource ID and the same
   content as cehcked-in version of foo.txt)? Or it should be foo.txt VCR
   itself? Then what is the value of DAV:displayname property of this
   resource?

RFC-3253 requires that a MOVE keep all the RFC-3253 defined
properties, so such a MOVE would have to expose the version history
resource itself at the new location (not a new resource, and not a
VCR).  It's DAV:displayname would be whatever was the DAV:displayname
of the VCR before the MOVE.  A server is likely to restrict the location
of version history resources to be in working collections and its
original server-defined location, which is why such MOVE's are
unlikely to be supported.

Cheers,
Geoff

Received on Monday, 8 April 2002 15:24:11 UTC