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

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 8 Apr 2002 15:23:33 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106690B54@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]

   So, PROPFIND with DEPTH=1 for working collection will return set of
   version histories, not VCR, 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?


   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

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

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC