Version-controlled collection resources - I am still missing something

Well, its been a day or two since my last question (or was it just the
weekend? :-), so here goes.

I am still missing a vital point (which may have been explained, but my
neurons have not connected yet) relating to version-controlled collection
resources. Either that or it was a good weekend and I cannot remember
what was said last week (blush)...

I can use VERSION-CONTROL to create a new version controlled resource
(VCR) by identifying a version resource (VR). If the VR holds the
versioning information for a collection, then the VCR will be a
collection resource.

What bindings will be in the VCR collection resource? Will it be an
empty directory? Or will it automatically have bindings to version
histories? (and what does this mean??) Or...

Basically I am trying to understand how to create a workspace, then
populate it with with non-checked-out version control instances.
What commands do I need to do? If I do a VERSION-CONTROL command,
I can get a version-controlled-resource referencing a version-resource.
I understand this for a non-collection resource. But what about a
collection resource? I guess I get a collection with bindings to
version histories(????). Do I then use VERSION-CONTROL to replace the
bindings to version-history resources with bindings to version-controlled
resources? Or using VERSION-CONTROL to get a collection, does it
magically walk the whole collection tree from that point down creating
version-controlled-resource instances to all the resources in the
whole collection tree?

Hmmm. Not sure if the above makes much sense. Put simply, I have
a project with a tree of files. I want to create a workspace (for
server side versioning) then get a read-only copy of all the files
("Get Latest Version" in Microsoft Visual Source Safe) in the project.
I do not want to check them out yet. I want to do that later.
I just want to read the files then later check out the files I
actually want to modify. I am not sure of the complete sequence
of commands to do this. (With an example of such a sequence, all
my other questions probably go away.)

I tried to work it out reading the spec. (Don't both commenting on
the following if you have replied already clearly to the above.)
I think the answer to the above makes a big difference to my understanding
of the following. The DeltaV spec I have says

    14 Version-Controlled-Collection Feature
    Although a collection version only records the version-controlled
    bindings of a collection, a version controlled collection MAY
    contain both version-controlled and non-version-controlled
    bindings. Non-version-controlled bindings are not under version
    control, and therefore can be added or deleted without checking
    out the version-controlled collection.
    
So collections can contain both version-controlled and
non-version-controlled resources at the same time.
I assume that I can create and delete non-version-controlled resources
in the directory whether the collection is checked-out or not.

This continues with text talking about Lock Null resources.

    This feature is essential for the support of lock null resources,
    since a lock null resource is a temporary internal member of a
    collection that should only exist for the duration of the lock, and
    should not be captured in the version history of tha coolection.

If we do not have lock null resources, does this mean that we no
longer need to be able to create non-version-controlled-resources
under a version-controlled collection? (My guess this is not the case,
but it seemed topical.)

    14.10 Additional CHECKOUT Semantics
    ... If the request has been applied to a collection version, the
    new working collection MUST be initalized to contain a binding to
    each of the history resources identified in the
    DAV:version-controlled-binding-set of that collection version.

Does this delete references to any other bindings to non-version-controlled
resources that are in the working directory? My guess is not. But what
if there is a collision? (Eg: a non-version-controlled resource
is created called FOO then the collection is checked out which contains
a FOO binding. Does the CHECKOUT fail? etc.)

Or, if using VERSION-CONTROL to get a collection resource does
populate it with all bindings (ie, the working collection is not
empty), then the only way to get a collision is to have deleted
the binding before hand (in which case there is probably no danger
as you probably are not permitted to delete a resource-controlled
binding if the collection resource is not checked out).

Thanks as always.

Alan

ps: Boy this can be a tounge/brain twister!

Received on Monday, 2 July 2001 03:30:22 UTC