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

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

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Thu, 5 Jul 2001 16:41:45 +1000
To: "Clemm, Geoff" <gclemm@rational.com>
Cc: DeltaV <ietf-dav-versioning@w3.org>
Message-ID: <20010705164145.F23551@io.mds.rmit.edu.au>
On Thu, Jul 05, 2001 at 12:54:57AM -0400, Clemm, Geoff wrote:
> 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.

I had used the term "get" loosely - I did not mean a HTTP get.
When you use VERSION-CONTROL to create a new version-controlled
collection, it (as you described previously) will create a complete
tree of collection and leaf non-collection resources. No content
will be retrieved. Then the client must use UPDATE on every single
binding in the whole tree created to change it to the desired version.

My comment on performance was not volume of data (you do not download
the content of the resources), just the number of individual requests
required. You need at least one HTTP request/response per recource
in the tree created from the VERSION-CONTROL command.

> 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.

This is a useful trick to remember.

However, as soon as you UPDATE the collection to a later version, it will
then populate one level down in the tree. For every internal member,
you then need to UPDATE it to the desired version (possibly creating
new child version-controlled collection resources). The client really
needs to start from the top and recursively do UPDATE requests on each
request one by one until you get down to the bottom. So there are lots
of little requests required.

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

For server-workspace package how does this work? I create a new
workspace for the first time, then want to populate it. So no existing
workspace exists? 

Or if I have a workspace and want to update everything to the latest
versisions (since other people have made changes), then again, I need
to potentially do lots of separate requests.

I think the answer is "tough luck" (or use baselines - I have not tried
to understand them yet). Unless the version history of versions modelled
a primary version series with other branches off to the side (ala CVS),
it is not possible to say 'VERSION-CONTROL at this time point for the
whole tree'.

I am assuming introducing the concept of multiple linear version series
is too much for the DeltaV community to swallow in terms of change.
It would support the CVS and DMA approaches quite closely. (eg:
Create version-controlled resources for 'whatever version existed at
date X' / 'latest version' for the version series called 'primary'/'1.1.1'/
'with label Y'). It would allow a single VERSION-CONTROL command to get
the correct version across a hole collection tree. But it is not possible
with the current simplistic model of versions having predecessors and
successors. It requires something such as the more detailed model of
identifying linear series of versions (so you can find the last in a
linear series - you cannot find the last in a graph and have it make sense).

Received on Thursday, 5 July 2001 02:42:18 UTC

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