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

RE: Versioning collections question

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 26 Jun 2001 22:34:21 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103770666@SUS-MA1IT01>
To: DeltaV <ietf-dav-versioning@w3.org>
   From: Alan Kent [mailto:ajk@mds.rmit.edu.au]

   On Tue, Jun 26, 2001 at 01:18:22PM -0400, Clemm, Geoff wrote:
   > So with a URL like /foo/a, how do you know which of the many
   > possible bindings named "a" between /foo and some other resource
   > are to be used?  Unfortunately, the "independent binding" model
   > breaks down in the presence of versioning.

   I am sorry - are you saying a collection can have multiple bindings
   to different resources using the same name? Or are you talking
   about different versions of the same collection having different
   bindings of "a" to other resources?

The latter, i.e. different versions of the same collection having
bindings of "a" to different resources.

   ... If user A checks
   out a version-controlled collection and adds a new file. User B then
   checks out the same version-controlled collection and adds a different
   new file. (I am thinking of a CVS like model here - I don't know the
   correct DeltaV jargon for this yet.) Both users then try to check
   in the resource. In CVS, the second commit might fail with a conflict,
   or CVS might be smart enough to do the merge. In DeltaV, what is
   expected to happen? I conflict report? A merge by the server? A merge
   by the client doing the second commit?

The behavior differs depending on whether your client included the
DAV:apply-to-version flag with the CHECKOUT.

Without the DAV:apply-to-version flag, the server must support the
"server-workspace" package.  The CHECKOUT is "in place", and the VCR
itself is in a checked-out state.  In this case, the attempt by user B
to checkout that VCR will fail (with an "already checked out" error).
In order to work in parallel, the second user would need to allocate a
second workspace on the server, populate it with its own VCR for that
collection (and that collection's members), and work in that second
workspace.  One user could then "MERGE" the new collection version
created in the other workspace, resulting in a conflict report, which
the user would resolve based on the information displayed by its

If the DAV:apply-to-version flag is included in the CHECKOUT, the
server must support the "client-workspace" package.  The CHECKOUT
leaves the VCR in the checked-in state, but creates a working
collection.  The second CHECKOUT creates a second working collection.
When these users do a CHECKIN, it creates new versions (on separate
lines of descent).  When the user wants to make his changes visible,
the client should request a MERGE with the DAV:no-checkout flag of the
new version to the version-controlled collection.  If there are
conflicts, the client should create a new working resource, MERGE the
new version into that working resource, CHECKIN the result, and again
request a MERGE with the DAV:no-checkout flag of the new version to
the version-controlled resource.  If no one has changed the
version-controlled collection, this time the MERGE will succeed.

   So just to clarify, if I check out /foo and /foo/a/ but not /foo/b,
   then in my workspace(??), what resource type is /foo/b? I was
   reading through the archives a bit and came across the term
   "version selector".  Is /foo/b a "version selector"?

Version selector is another piece of terminology that was rejected
because it was misleading.  /foo/b is a "version-controlled resource"
(assuming it is under version control), as are /foo and /foo/a.

Note that a version-controlled resource may be a member of a workspace
(a workspace is just a special kind of collection), but it doesn't
have to be.

   Finally, Tim said:
   > Just to confuse things more :-) a version-controlled collection can
have a
   > version-controlled internal member with the same name as a
   > non-version-controlled-member, and they are considered distinct.
   > this is all explained in Section 14.


   Hmmm. I think my eyes must have glazed over by the time I got to
   section 14. I had better go read it again more carefully! It should
   make more sense this time.

I'd suggest saving the DAV:eclipsed-set for the very end,
since it is the most subtle feature in versioned collections
(arguably, the most subtle feature in the whole protocol).

   Thanks everyone for the feedback.

You bet!  All excellent questions.

Received on Tuesday, 26 June 2001 22:34:53 UTC

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