- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Tue, 26 Jun 2001 10:44:46 +0100
- To: DeltaV <ietf-dav-versioning@w3.org>
Alan Kent <ajk@mds.rmit.edu.au> wrote: > On Tue, Jun 26, 2001 at 05:17:00PM +1000, Alan Kent wrote: > > Or put another way, the URI bindings to members of a collection are > > a part of the parent collection and so are versioned with the member > > collection. > > An interesting follow on is that to check out a collection, I always > get out all the members. When you checkout a version of a collection you are not checking out the members of the collection. By checking out a collection you make the collection resource (including its internal members == "bindings") mutable. This means to rename /a/b to /a/c then the collection /a/ must be mutable, but /a/b and /a/c can be immutable versions. Same for delete, you can delete the binding /a/b if /a/ is mutable even if /a/b is immutable. > I cannot get partial subtrees. > ("I want to check out /foo and /foo/a/..., but not /foo/b" is not > possible since the container /foo will contain the "b" binding > so "b" will be visible). I guess "b" does not have to be in the > "checked-out" mode or something - ie, read only (??). > I don't know if this is important. > > Hmmm, another question. What do bindings identify? A particular version > of a collection? The latest version of a collection? A version of a collection captures its dead properties and its bindings to version-controlled resources in terms of their version history. It does not capture any live properties or bindings to non-version-controlled resources. So if you PROPFIND depth 1 on a version of a collection you will discover the internal members are bound to version history resources. Indeed, if you check out a version of a collection you will get a working collection whose internal members are bindings to version history resources. A version-controlled collection contains bindings to both version-controlled and non-version-controlled members. Typically, workspaces are used to create unambiguous configurations of version-controlled resources by ensuring that they contain only one version-controlled resource per version history. > If I check in > a new version of a collection, does the parent collection need to be > modified to point to the new version? Does checking in the parent > collection in turn require the check in of its parent, all the way > up to the root of the configuration? Does this mean adding a new > file to a configuration always results in a versioning riple from > that resource's parent collection up to the root collection? No, we explicitly wanted to avoid this. The explaination is given in deltav-15.1 Section 14 para.2. > Ok, I think this means I don't understand how collection versioning > works because I don't know how a binding in a collection identifies > the member. Does it identify a version history, a particular version, > or what? What semantic information does a version of a collection > hold? Yup, its a version history for the reason you gave above. Just to confuse things more :-) a version-controlled collection can have a version-controlled internal member with the same name as a non-version-controlled-member, and they are considered distinct. Again, this is all explained in Section 14. Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452
Received on Tuesday, 26 June 2001 05:50:44 UTC