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

   From: Alan Kent [mailto:ajk@mds.rmit.edu.au]

   On Mon, Jul 02, 2001 at 10:41:27AM -0400, Clemm, Geoff wrote:
   > VERSION-CONTROL /ws/alan/src 
   > <D:version> <D:href> http://repo/coll-ver/345 </D:href> </D:version>
   ...

   Ok, thanks, just one final little question to make sure I completely
   understand it. Is /ws/alan a workspace? or /ws/alan/src?

It was /ws/alan.

   That is, do I do the VERSION-CONTROL on the workspace or under
   the workspace?

The protocol wouldn't let you specify VERSION-CONTROL with
a specified version on the workspace, so you could only apply
VERSION-CONTROL to the workspace itself if you were willing
to create a new version history for the workspace collection.

   I am a CVS user so I find things easy to relate back to CVS. In my mind,
   the area on my local hard disk where I check out files is semantically
   similar to a server-side workspace. (I know, the CVS area on my hard
   disk is more like a client-side workspace, but I am just trying to
   work out clean semantics to describe it to others with.)

This analogy works fine.  Imagine that you wanted to support
clients that had no local persistent storage.  Then your CVS server
would allow these clients to create work areas on the server,
where they could create whatever VCR's they needed.

   Our source code is broken up into multiple CVS modules. So when
   I do a cvs co, for a new 'workspace' I need to use cvs co to
   get the modules (top level directories) that I want for that
   workspace. For example,

       % mkdir ~/work/DMS
       % cd ~/work/DMS
       % cvs co DMS TOOLS SUPPORT

Assuming that /home/alan is your server side "home" and /cvsroot is
your repository:

MKWORKSPACE /home/alan/work/DMS

PROPFIND /cvsroot/DMS
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-23
VERSION-CONTROL /home/alan/work/DMS/DMS
<D:version> <D:href> /version-url-23 </D:href> <D:version>
MERGE /home/alan/work/DMS
<D:source> /cvsroot/DMS </D:source>

PROPFIND /cvsroot/TOOLS
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-29
VERSION-CONTROL /home/alan/work/DMS/TOOLS
<D:version> <D:href> /version-url-29 </D:href> <D:version>
MERGE /home/alan/work/DMS
<D:source> /cvsroot/TOOLS </D:source>

PROPFIND /cvsroot/SUPPORT
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-35
VERSION-CONTROL /home/alan/work/DMS/SUPPORT
<D:version> <D:href> /version-url-35 </D:href> <D:version>
MERGE /home/alan/work/DMS
<D:source> /cvsroot/SUPPORT </D:source>

       % mkdir ~/work/WEB
       % cd ~/work/WEB
       % cvs co WEB WEBADMIN SUPPORT

MKWORKSPACE /home/alan/work/WEB

PROPFIND /cvsroot/DMS
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-43
VERSION-CONTROL /home/alan/work/WEB/WEB
<D:version> <D:href> /version-url-43 </D:href> <D:version>
MERGE /home/alan/work/WEB
<D:source> /cvsroot/WEB </D:source>

PROPFIND /cvsroot/WEBADMIN
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-49
VERSION-CONTROL /home/alan/work/WEB/WEBADMIN
<D:version> <D:href> /version-url-49 </D:href> <D:version>
MERGE /home/alan/work/WEB
<D:source> /cvsroot/WEBADMIN </D:source>

PROPFIND /cvsroot/SUPPORT
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-45
VERSION-CONTROL /home/alan/work/WEB/SUPPORT
<D:version> <D:href> /version-url-45 </D:href> <D:version>
MERGE /home/alan/work/WEB
<D:source> /cvsroot/SUPPORT </D:source>

   I might also check out a branch to fix a bug using a label.

       % mkdir ~/work/WEB.rel1
       % cd ~/work/WEB.rel1
       % cvs co -r release-1 WEB WEBADMIN SUPPORT

Assuming you model labels as special workspaces (why introduce all the
ugliness of labels when you can just use workspaces consistently :-),
and assuming your label workspaces are at /cvsroot_labels :

MKWORKSPACE /home/alan/work/WEB.rel1

PROPFIND /cvsroot_labels/release-1/DMS
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-63
VERSION-CONTROL /home/alan/work/WEB.rel1/WEB
<D:version> <D:href> /version-url-63 </D:href> <D:version>
MERGE /home/alan/work/WEB.rel1
<D:source> /cvsroot_labels/release-1/WEB </D:source>

PROPFIND /cvsroot_labels/release-1/WEBADMIN
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-69
VERSION-CONTROL /home/alan/work/WEB.rel1/WEBADMIN
<D:version> <D:href> /version-url-69 </D:href> <D:version>
MERGE /home/alan/work/WEB.rel1
<D:source> /cvsroot_labels/release-1/WEBADMIN </D:source>

PROPFIND /cvsroot_labels/release-1/SUPPORT
<D:prop> <D:checked-in/> </D:prop>
=> /version-url-65
VERSION-CONTROL /home/alan/work/WEB.rel1/SUPPORT
<D:version> <D:href> /version-url-65 </D:href> <D:version>
MERGE /home/alan/work/WEB.rel1
<D:source> /cvsroot_labels/release-1/SUPPORT </D:source>

   In the above model, I would say ~/work is not a workspace - I have
   different versions of the same resources checked out which is not
   permitted in a workspace.

Correct.

   So I guess ~/work/DMS ~/work/WEB and ~/work/WEB.rel1 are the
   equivalent to workspaces.

Yes.

   The CVS repository consists of

       .../cvsroot/DMS
       .../cvsroot/SUPPORT
       .../cvsroot/TOOLS
       .../cvsroot/WEB
       .../cvsroot/WEBADMIN

   If .../cvsroot is a project in DeltaV, then the above CVS example is
   not possible using DeltaV (I think).

DeltaV has no special "project" resource.  You would probably
model /cvsroot as a collection (possibly under version control,
possibly a workspace).

   Because you would do a VERSION-CONTROL
   on .../cvsroot to ~/work/DMS or whatever and get all of the DMS, SUPPORT,
   TOOLS, WEB, and WEBADMIN directories created locally.

Currently, the workspace collection itself cannot share a version
history with another workspace, so you can't do something like that.
This is because you can only specify an existing version if the
request-URL of the VERSION-CONTROL identifies an unmapped URI.
I suppose we could relax that constraint, if folks thought this
was an important use case (this was just an error check, to make
sure clients didn't blow away the current state of the resource
at the request-URL).

       MKWORKSPACE /work/DMS
       VERSION-CONTROL /work/DMS
       <D:version> <D:href> http://repo/coll-ver/345 </D:href> </D:version>
	   <!-- where coll-ver/345 is .../cvsroot -->

You couldn't use VERSION-CONTROL with a specified version on
a collection that exists, unless we relaxed the constraint
I mentioned above.

   The above makes me slightly uneasy in that I first created a workspace,
   but then I have replaced it (?) (augmented it? modified it?) with a
   VCR for the root collection.

Well, if we leave in the current constraints, there is no need to
be uneasy (:-).

   Maybe I have to create one additional
   layer of subdirectory so the root of the project tree appears under
   the workspace directory instead(?).

Yes.

   Or I guess I can use VERSION-CONTROL to get sub-directories of the
   project(?).

       MKWORKSPACE /work/DMS
       VERSION-CONTROL /work/DMS/DMS
       <D:version> <D:href> http://repo/coll-ver/999 </D:href> </D:version>
	   <!-- where coll-ver/999 is .../cvsroot/DMS -->
       VERSION-CONTROL /work/DMS/TOOLS
       <D:version> <D:href> http://repo/coll-ver/888 </D:href> </D:version>
	   <!-- where coll-ver/888 is .../cvsroot/TOOLS -->
       VERSION-CONTROL /work/DMS/SUPPORT
       <D:version> <D:href> http://repo/coll-ver/777 </D:href> </D:version>
	   <!-- where coll-ver/777 is .../cvsroot/SUPPORT -->

Yes.  (That's the approach I used above).

   Are both of these OK? My understanding is DeltaV was being proposed
   as a possible replacement for the underlying CVS protocol, in which
   case my example must somehow be possible. Have I understood things
   correctly?

Yes!  The only thing you missed was that constraint that you can't
apply VERSION-CONTROL with a specified version to an existing resource.
But we could certainly remove that "error check" if folks believe 
we should (I'm happy either way).

Cheers,
Geoff

Received on Monday, 2 July 2001 22:49:48 UTC