Re: Finding the version of a resource in a Version-Controlled-Collect ion...

Alan Kent <ajk@mds.rmit.edu.au> wrote:

> On Tue, Jul 10, 2001 at 10:28:50AM +0100, Peter Raymond wrote:
> > Despite some excellent e-mail threads recently regarding
> > Version-Controlled-Collections
> > I am still not clear how to find the specific version of a
> > resource which is referenced by a version of a collection resource.
>
> I think the answer is you don't. A collection does not identify exact
> versions of resources that are referenced. If it did, then every time
> a member of the collection was versioned, the collection itself would
> have to be versioned. Versioning the collection would in turn cause
> its parent collection to be versioned, and so on up the tree. This is
> not really acceptable, so collection histories do not identify specific
> versions, only a version history.

I agree.

> This felt weird to me at first, but it made sense eventually. I like
> relating things back to CVS (because I use it a lot). In CVS, each
> file has its own version history with version numbering. Not all files
> in a directory have the same version numbers. So when you do a cvs update
> or cvs checkout, you are actually asking each file individually for
> 'the latest version' or 'a version with this label'. You do not use
> CVS to say 'get me version 1.2 of every file in a directory' because
> the files have individual version numbering.

CVS doesn't have a baseline resource, rather it lays down a consistent
label to identify a configuration of resources.  This is also possible in
DeltaV, however, the label may be moved to a different version.  A
'baseline' resource is an immutable version of a configuration.

> The same is true for collections. To do a VERSION-CONTROL in DeltaV,
> for every single resource you get a version-controlled resource for,
> its up to you to select the particular version you want.

Not quite sure what you meant here, but it is true that you can create new
version-controlled resources using VERSION-CONTROL with a DAV:version
element body to 'initialize' the version-controlled resource with a
particular DAV:checked-in version.

> Collections are a bit weird in that asking for the collection actually
> gives you a tree of all the member resources (including nested
> collections etc.).

Again I'm not sure what you mean by "ask for" a collection?
When you create a new version-controlled collection that is 'initialized'
from an existing collection version, the members of the version-controlled
collection will be bound to undefined versions of the version-histories (of
each member of the collection version).

That's a bit of a mouthful, so let me try that another way:
Given a collection version http://.../vr1 with a binding, say "bar", to the
version history http://.../his1.
If you create a new version-controlled collection and specify
http://.../vr1 as the DAV:version in the body:
    VERSION-CONTROL /foo HTTP/1.1
    ...
    <DAV:version>http://.../vr1</DAV:version>
    ...
Then you will have a new version-controlled collection called /foo that has
a member /foo/bar that refers to an undefined version of http://.../his1

> The standard says however that in this case you
> always get the root version in the history (unless its already in the
> workspace in which case it binds to the existing VCR in that workspace).
> Its up to the client to then say "no, I don't want the root version
> for this resource, I want version X" where its up to the client to
> work out what version X is.

It was discussed that the member should be bound to the DAV:root-version
but counter-argued that the root version is unlikely to be the required
version, and since we can't choose the best version it is probably better
to leave it undefined (Alan's point about workspaces notwithstanding).
Clients are likely to fix-up the bindings created this way.

> At least that is my current understanding. Please not however that
> I have not read up properly on activies and baselines yet, so the
> above may be different when using those concepts. But I beleive the
> above is correct with respect to the fundamentals of the DeltaV
> versioning.

Baselines are much more useful since they capture the deep state of a
collection (a.k.a. configuration).

Regards,
Tim

Received on Wednesday, 11 July 2001 05:28:34 UTC