Re (4): collection version resources

Hi Goeff, I still try to understand some things in the draft :-)

You wrote:
> Using deltav terminology, you want baselines to contain subbaselines,
> which they do (with the subbaseline-set property).
> 
>    Now just a short description what I would like to be able to do
>    with DELTA-V: Because I model my software for many years in what I
>    called software units.  A software unit was mapped to a directory
>    below a base directory which again could contain other software
>    units or individual files.
> 
> To allow more than one system to use one of those units, I'd recommend
> putting the shared units "next to" rather than "below" the system that
> uses them.  But that is of course your choice.
So it seems that I'm ok. But nevertheless could you give an example for the
use of subbaselines ? I'm not sure whether it must be in the draft, but
I think I need some more information on them.
A question to the server writers out there: Is it clear to you how to implement
subbaselines ?
Perhaps you could also expain what it would mean when shared units are "below"
the system that uses them. And what's the difference between a "below" collection
and a "below" subbaseline ? Because a baseline already captures a "deep version"
of a collection (Beginning of 10)

>    Neverthess my question is whether it would be possible/useful to
>    give a short formal definition of DELTA-V concepts somewhere as an
>    EBNF grammer like I'm trying with my stuff. Please don't look at
>    the semantics but just the syntax. A small grammer can tell you a
>    lot sometimes where you need a lot of text to describe it in prose.
>    I changed it a little bit after reading Geoff's comments, thanks.
> 
> I have written a Rose model that does this.  If I can carve out some
> time, I'll publish this to the deltav web site.  I agree that it would
> be
I still would like to see this Rose model. Could you put it somewhere
on the Delta-V page in a format also readable by non Rose users ?

A while ago there was the discussion on mutability. Finally you decided to
kill it by variants.
Are the mutable champions happy now ?
I still think my proposal with a simple lifecycle where the initial state
is still mutable would be easy to understand. Also it would give some guidelines
how to implement more complex lifecycles which you find in many CM tools.
Also the discussion on human readable version URLs suddenly seems to be
finished.
When I had a look at the options we have, I noticed that they are orthogonal
at first glance. But nevertheless there are certain sets of options which
should be implemented together to get a certain functionality.

Cheers, Edgar


-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Native Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Monday, 15 January 2001 19:01:02 UTC