RE: Version-controlled collection resources - I am still missing something

   From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]

   "Clemm, Geoff" <gclemm@rational.com> wrote:
   > ... the
   > DAV:version of the internal member MUST be the DAV:version
   > of that other member; otherwise, the DAV:version MUST be
   >  the DAV:root-version of the version history.

   I guess that picking the DAV:root-version is the obvious choice
   from a protocol-writer's perspective since it is well defined in
   the spec.  It also provides behavior that is predictable by the
   client since they know the root version.  However, it would seem to
   me that clients would 99.9% of the time have to UPDATE / MERGE all
   of the version-controlled resources created using this rule.

I think the probability is significantly lower than this because a
users often only wants a subset of the components of a system in their
workspaces.  If an implementation has the root version of a collection
history always be an empty collection (which is a very sensible
choice), then all of the sub-directories you don't care about will by
default show up in their empty initial state.  This allows you to
limit the expense of Depth PROPFIND's on a workspace.

Also, since you can initialize your entire collection with a single
MERGE or UPDATE request, it makes sense to chose a default that will
produce the most minimal initial configuration, which is what the root
version is likely to produce.

   How do you feel about making the new version-controlled resources
   have a DAV:checked-in of the (chronologically) latest version
   instead?  I have no great desire for this, but just think it may be
   more client friendly.

In the presence of forking, "latest" is a very bad choice, because it
would cause the initial state to unpredictably jump from one line of
descent to another.  So I believe that selecting the DAV:root-version
is significantly superior.

Cheers,
Geoff

Received on Wednesday, 4 July 2001 13:28:30 UTC