BASELINE option

Hi Geoff,
it seems you also made some changes in baselines for draft 13.
I think it's clearer now. Nevertheless some questions.
When asked a while ago about the difference between version controlled
collections and baselines you told me that baselines are a depth 1 thing.
If I understood that correctly this would mean that a baseline doesn't
capture states of collections and their contents recursively.
On the other hand I learned at one time that "member of collection" means
"normal" and collection members.
So it's not clear to me what you mean here.
BTW, I use baselines which don't catch collection members. If I want them in my
baseline I add them as a subbaseline. Also baselines only exist in the context of
a workspace in my system. So a subbaseline can be identified by it's relative path
from workspace root.
As a remark, I'm still not sure why we need the terms "configuration" and "baseline".
Isn't a baseline just a version of a configuration ?
You argue correctly that a baseline is efficient by containing just version
and path of the resources it contains.
The same is valid for subbaselines. Imagine a medium sized baseline containing
1000 resources.
Now you need a bugfix in one resource. You create a new baseline of the configuration
duplicating 999 entries from the predecessor.
Compare this with a baseline containing e.g. 10 subbaselines containing 100 resources.
If you change a resoure in a subbaseline you get a new version containing
99 duplicated entries and a new one. I addition you have to update the super baseline
containing 9 old and 1 new entries. A long way to the 1000 new data items you
get with a single unstructured baseline.
And now imagine how cheap new baselines will become if you work on a lightly 
bigger configuration containing 10000 resources e.g. containing 10 subbaselines
with 1000 resources each, compared to a "simple" baseline.
In 12.2.1 (DAV:subbaseline-set) you write: "A server MAY reject attempts to modify
the DAV:subbaseline-set of a checked out configuration"
My interpretation of this statement is, that a server understanding BASELINE at least
must know about checking out subbaselines. This sounds plausible. Because if not
it couldn't work with any baseline containing subbaselines.
If that's right some comments:
It MAY reject modifying the subbaseline-set. But probably it can change some
resources and create a new baseline containing the old subbaselines ?
So it already has to know a lot about subaselines, but can't do all with them.
But not much is missing here. This can be confusing.
I think make the whole subbaseline stuff optional or remove the MAY sentence.

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 Saturday, 17 February 2001 15:05:15 UTC