Re (2): Definition of a configuration

"Clemm, Geoff" <gclemm@rational.com> wrote:
>    From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]
> 
>    Peter Raymond <Peter.Raymond@merant.com> wrote:
> 
>    > "A configuration is a set of resources that consists of a root
>    > collection and all members of that root collection except those
>    > resources that are members of another configuration"
> 
>    > "A baseline is a version resource that captures the state of each
>    > version-controlled member of a configuration"
> 
>    > The configuration DOES include members that are not
>    > version-controlled, but the baseline does NOT capture them.
>    > Right?
> 
> Correct.
> 
>    The spec is saying that but I think it's wrong :-)
> 
> One could define it either way, as long as the definitions are used
> consistently.
Here we agree. I also think that the power of the protocol will be the same
either way.

> Since the spec has gone through IESG last call, we'll just have to live with the
> current definitions.
OK, you say it's too late for this discussion now for formal reasons. But will
there be another open window sometime in the future when this topic can be
discussed again and a consensus of the group could change the definition of
a configuration ?
I don't know whether my proposal would get a majority but nevertheless it's 
important to know whether now it's the last chance.
My experience in developing SW is that it's cheapest to correct problems as soon as
possible in the lifecycle. You can also find that in the literature :-)

>    In my understanding A BASELINE IS A VERSION OF A CONFIGURATION.
>    The purpose of a version is to capture the state of the thing it's
>    a version of.  So if a configuration can contain
>    not-version-controlled members and a baseline doesn't capture them
>    a baseline isn't really a version of a configuration.  At least in
>    the sense I defined the meaning of 'version' above.
> 
> I think the current approach of the specification is simpler, since it
> effectively says that anything you can find with a depth:infinity
> PROPFIND is a member of that configuration.  But whether or not it
> is simpler, it is what will appear in the standard.
Yes, the definition of a configuration is simpler, but OTOH the definition
of a baseline is more complex. It's just a matter of moving the restriction
'version-controlled members' between configuration and baseline.
I still think that our current definition contradicts the common meaning
of 'version' (as detailed above). Here I see a source of misconceptions.
I would regret it if a basic term of 'configuration' management is flawed
from the beginning.
I expect 'configuration' to become a cornerstone of future versioning
because in SW development and also website management you don't deal with
independent resources normally (This doesn't mean that I want to belittle
the effort necessary to do core versioning).

>      "A configuration is a set of resources that consists of a root
>       collection and all version-controlled members of that root collection
>       except those resources that are members of another configuration"
> 
>      "A baseline is a version resource that captures the state of each
>       member of a configuration."
> 
> This would not allow you to talk about non-version-controlled
> configurations.  I think this would be unfortunate, since it is
> a useful concept even if you aren't doing versioning.
Why not ? If you talk about a root collection which isn't under baseline-control
containing version-controlled resources you talk about a non-version-controlled 
configuration.
And if you mean a root collection without version-controlled resources, then
what would be the purpose of calling it a configuration ? If you put it under
baseline-control nothing would be captured.  

>    I think we should make clear the difference between the
>    configuration (The set of version controlled resources. A logical
>    entity) and the collection which just serves as a temporary
>    anchor/root to "display" the configuration.
> 
> The specification makes a clear distinction between the configuration
> (which is a set of resources), and the root collection of a
> configuration (which is a single resource).  How is the root
> collection any more "temporary" than any other part of the
> configuration?
A baseline (which is also a configuration) can exist without a root collection.
When you checkout a baseline to a root collection you can choose (nearly) any
collection you want. In this sense the root collection isn't a part of the
configuration. It'a like loading a document to the editor buffer.
You wouldn't say that the buffer is a part of the document. It's just a means
to work with it.

> One could define it this way, but we didn't (:-).  That's one of the
> nice thing about locking down a standard ... you can stop debating
> over terminology, and get on with the implementations (:-).
But nevertheless I can try it and raise my voice if I think that
the terminology is misleading.
Changing the definitions wouldn't change the functionality, so perhaps I'm 
sort of a purist. Probably this also shows in my favorite programming languages.
I prefer e.g. Oberon and Python to C and C++ :-)
But I don't think many changes in the spec would be necessary. Probably at some
places moving a 'version-controlled resources' or exchanging a 'collection' by
'configuration'.

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 Monday, 29 October 2001 17:01:36 UTC