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

   From: Alan Kent [mailto:ajk@mds.rmit.edu.au]

   But I agree that the current semantics seem quite inefficient. 99% of
   the time, getting the first version in a series will not be what is
   wanted.

There may be some confusion here between what is done on the server
and what is done on the client.  A server does not need to "get" any
version, since an efficient implementation will just set the
DAV:checked-in property of the VCR, and not make an actual copy
of the content and dead properties of the version.

Also, remember that the only time this "pick the initial version"
functionality is invoked is when your server supports versioned
collections, and you are using VERSION-CONTROL to create a new
version-controlled collection from a specified version of an existing
version history.  Only in this case does a version need to be selected
for the internal members of that new version-controlled collection.
When you use VERSION-CONTROL to create a new (non-collection)
version-controlled resource, you explicitly specify what version you
want in the VERSION-CONTROL request.

And in the version-controlled collection case, if your server is
sensible, and has the root version of a collection always be an empty
collection, then the server does no extra work for the VERSION-CONTROL
request, because it just creates the
version-controlled collection with no members at all.  You then use
UPDATE or MERGE to initialize this collection.

   For a CVS repository for our code, we would update/check out
   potentially thousands of files in a single request. We don't keep
   a small number of files per 'workspace' when using CVS. We get the
   whole lot because when compiling subsystem 'X', it includes header
   files from subsystems 'A', 'B', .... 'W' all which need to be available.

I assume by get, you mean using the HTTP GET method to get the content
from the server?  If so, you wouldn't be requesting this until you
have configured your workspace properly, i.e. after you have done the
MERGE that causes the workspace collection to display the versions you
want.

   I have not read the spec closely enough, but if its not possible now,
   is there a way to say 'VERSION-CONTROL using label'? If so, maybe
   labels could be used to 'get most popular choice' or something??

Since we're talking about configuring workspaces, we would need to use
functionality provided in the server-workspace package, which would be
baselines, not labels.  And yes, you could use a single
BASELINE-CONTROL request to initialize the collection in one round
trip.

Note that if your server does support labels, you can use UPDATE
with a Depth and Label header to configure the workspace.  Since
the initial VERSION-CONTROL request is inexpensive, there would be
no reason to bundle the UPDATE functionality into the VERSION-CONTROL
request (2 round trips is not an unreasonable number of requests
to configure a workspace).

   Or during checkin etc, is it worth having a property on a version
   saying "I am now the best default choice" - similar to the DMA concept
   of the latest version in the primary version series.

The "best default choice" is appropriately modeled as a workspace
(for the server-workspace packages) or a label (for the client-workspace
packages).

Cheers,
Geoff

Received on Thursday, 5 July 2001 00:48:21 UTC