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

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

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Tue, 3 Jul 2001 09:43:56 +1000
To: DeltaV <ietf-dav-versioning@w3.org>
Message-ID: <20010703094356.C777@io.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?
That is, do I do the VERSION-CONTROL on the workspace or under
the workspace?

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.)

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

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

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

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.

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

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). 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.

    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 -->

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. Maybe I have to create one additional
layer of subdirectory so the root of the project tree appears under
the workspace directory instead(?).

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 -->

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?

Alan
Received on Monday, 2 July 2001 19:44:28 GMT

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