Re: Version-controlled collection resources - I am still missing something

> Actually, the requirement is that only one version-controlled resource
> from a given version history can be a member of a given workspace.
> This sentence should be rewritten to make that clear.  How about:
> 
>  If the internal member is a member of a workspace, and there is
>  another member of the workspace for the same version history, those
>  two members MUST identify the same version-controlled resource.

This made a big difference to my understanding, and made a big difference
to our planned implementation. I was planning to only permit collection
resources have one parent. That is, allow non-collection resources to
have multiple bindings to them (that is, appear in multiple parent
collections). But the above indicates that I need to do this for
collections too.

I was discussing it here internally saying

    You can create a workspace, then pick whatever collection in the
    project tree you want to make available to work on. [Project tree
    is my jargon, not WebDAV/DeltaV]

    For example, if I had a project with the following collections

	/DMS
	/DMS/src
	/DMS/src/cpp
	/DMS/src/perl
	/DMS/src/java
	/DMS/doc
	/DMS/doc/txt
	/DMS/doc/html

    Then a user may create a workspace /usr/ajk/myws then use
    VERSION-CONTROL to choose to make the /DMS/doc tree available
    as /usr/ajk/myws/doc. The tree would look like
    
	/usr/ajk/myws/doc
	/usr/ajk/myws/doc/txt
	/usr/ajk/myws/doc/html

I was then asked what happens if it was suddenly discovered that some
of the documentation to be changed was JavaDOC so the java files also
needed to be obtained.

    Well, you can just add them to your workspace using VERSION-CONTROL
    again as /usr/ajk/myws/java, so you end up with

	/usr/ajk/myws/doc
	/usr/ajk/myws/doc/txt
	/usr/ajk/myws/doc/html
	/usr/ajk/myws/java

I was then asked, what happens if it was suddenly realised that changes
also needed to be made to all the source code to change a badly designed
API. The user does not want to loose any changes made so far, or any
new files introduced etc. but not committed yet.

My new understanding is I can use VERSION-CONTROL again to say "lets
get the whole lot". This would end up with a tree of

	/usr/ajk/myws/doc
	/usr/ajk/myws/doc/txt
	/usr/ajk/myws/doc/html
	/usr/ajk/myws/java
	/usr/ajk/myws/DMS
	/usr/ajk/myws/DMS/src
	/usr/ajk/myws/DMS/src/cpp
	/usr/ajk/myws/DMS/src/perl
	/usr/ajk/myws/DMS/src/java
	/usr/ajk/myws/DMS/doc
	/usr/ajk/myws/DMS/doc/txt
	/usr/ajk/myws/DMS/doc/html

Where /usr/ajk/myws/doc IS the same resource as identified by
/usr/ajk/myws/DMS/doc. Similarly, /usr/ajk/myws/java IS the same
resource as bound to /usr/ajk/myws/DMS/src/java.
This is fine as I have not introduced cycles.

So why on earth am I mailing all this? I guess I am saying yes, I think
the additional text is worth while. It also highlights to me that it
makes life much easier if a collection resource can have multiple
bindings to it, not just for non-collection resources as I had originally
planned.

Tim asked previously if I was interested in writing up the answers I
have been getting for the FAQ. I might, but what I am first trying
to write up is a 'one way to implement WebDAV and DeltaV on top of
a DMA implementaiton.' DMA is a more generic document model with
versioning etc, but it maps quite nicely to DeltaV (phew!).
I find writing this sort of document forces me to understand all
the concepts in their entirety.

Alan

Received on Tuesday, 3 July 2001 04:14:51 UTC