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

Re (3): Re[2]: baselines & namespaces

From: <Edgar@EdgarSchwarz.de>
Date: Thu, 27 Dec 2001 07:56:39 -0500
Message-Id: <200112271256.HAA21653@tux.w3.org>
To: ietf-dav-versioning@w3.org
Cc: Edgar@EdgarSchwarz.de
As an introduction, what I want to be able to do with DeltaV.

Structuring Software with Components and it's Implementation in DeltaV
----------------------------------------------------------------------
At first there is the model:
A Software project is a component (To take the term which is used in Chapter 12
on BASELINE-CONTROL) consisting of resources.
For big Software projects it makes sense to break up the set of resources into
a set of smaller components (This also allows reuse of components in other
projects). The whole project now consists of a (possibly empty) set of resources and
a (possibly empty) set of subcomponents.
The resources of a component also can be structured in groups belonging together
logically.
That's in short what I had in my mind in the past when I was argueing for
subbaselines. 

Then comes the view provided by DeltaV:
A component is mapped to a baseline-controlled collection and called 'Configuration'.
It's resources are mapped to members of this collection. Component internal member
structuring is mapped to additional collections contained in the baseline-controlled
collection. A component version is called a 'Baseline'.
Subcomponents are also mapped to baseline-controlled collections (configurations)
of this view. Subcomponent property is implemented by adding the configuration
to the subbaseline-set property of it's 'master' configuration.
BTW, I expect subbaselines to be restored to the same relative path concerning
the baseline like when the baseline was created. There should be the necessary
properties to guarantee this.

"Clemm, Geoff" <gclemm@rational.com> wrote:
>	Edgar@edgarschwarz.de schrieb:
>    If /x/y is the root collection of another configuration it doesn't
>    belong to /x and if it also isn't a subbaseline of /x it must not
>    be created when /x is extracted in a new workspace.
> 
> It is important to distinguish between what the protocol does not
> require the server to do, and what it requires the server not to do.
Right.
> If your server supports baselines but not versioned collections, then
> it is not required to create /ws/kk/x/y when /repo/bl/22 is merged
> into /ws/kk, but it may do so.
Why should this be allowed ? A baseline "... captures the state of each version
controlled member of a configuration.". So /ws/kk/x/y isn't captured in the
baseline and I see no reason to restore it. 

> If your server supports baselines and versioned collectios, then it MUST create
> /ws/kk/x/y when /repo/bl/22 is merged into /ws/kk.
Again ! Why should this be required  ? /ws/kk/x/y wasn't captured in the baseline,
so there is no information how to restore it.
In your agenda BASELINE-CONTROL is giving different results depending on another
'competing' feature being supported or not. This shouldn't be.
Do you see why I have problems ? Perhaps you have a different model than me :-)
then please explain it.

Cheers, Edgar.


-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Active Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein
Received on Thursday, 27 December 2001 07:56:40 GMT

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