- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Thu, 5 Jul 2001 10:36:11 +0100
- To: DeltaV <ietf-dav-versioning@w3.org>
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