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

Re: Versioning collections question

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Tue, 26 Jun 2001 10:44:46 +0100
To: DeltaV <ietf-dav-versioning@w3.org>
Message-ID: <OF506C5510.FAD3085A-ON80256A77.00317F6E@portsmouth.uk.ibm.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT