Why members of a versioned collection revision must be versioned resources

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 15 Oct 1999 23:12:21 -0400 

Date: Fri, 15 Oct 1999 23:12:21 -0400
Message-Id: <9910160312.AA20299@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <852567CC.00704735.00@d54mta03.raleigh.ibm.com>
Subject: Why members of a versioned collection revision must be versioned resources

   From: jamsden@us.ibm.com

   Just out of curiosity, what would happen if a versioned collection
   revision contained unversioned resources? Seems like it would work
   fine.  The members of that versioned collection are selected based
   on the workspace revision selection rule which can select an
   unversioned resource too. What's the issue that drove this
   restriction?

The problem is a combination of server issues and client issues.

On the client side, if an unversioned resource were a member of a
versioned collection, the client would be faced with lost update
problems.  The client can't checkout that resource because it is not
versioned, and they can't put it under version control because
that would require changing the binding in that collection revision
(which you can't because a revision is immutable).  So the client
would have to keep track of which members are versioned resources
and which are not, since the update protocol for the two are very
different.  In addition, when you try to make a baseline of that
collection, do you allow it, knowing that the unversioned resource
can change at any time and thus violate client expectations about
the immutability of baselines?

On the server side, unversioned collection revision members are
very problematical since they are shared between every workspace
that selects that revision, and thus prevent the standard optimizations
that allow you to distribute workspaces to different servers.
Working resources present no problem, because they are local
to a workspace.  Revisions present no problem, because they are
immutable so every workspace can just have its own copy.  But if
you allow a collection revision to contain an unversioned resource,
any change to that unversioned resource should be immediately visible
to all other workspaces sharing that revision, making distributed
workspaces (i.e. workspaces that live on different servers) infeasible.

We need to balance these costs against the benefits provided by
having unversioned resources in collection revisions.  No benefits
come to mind ... (:-).

Cheers,
Geoff