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

Alan Kent <ajk@mds.rmit.edu.au> wrote:
>
> 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.

I agree with this analysis, and figure that the only solution is to use the
root-version-is-empty trick, or explicitly state that creating a
version-controlled collection this way does not have any members.

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

Yup, use baselines would be my answer.

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

or activities.

Regards,
Tim

Received on Thursday, 5 July 2001 05:37:11 UTC