Re: 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.

No, baselines *do* capture the deep versioned state of a collection (i.e.,
a configuration), but a baseline resource _itself_ is not a collection.
This must be what Geoff meant by 'baselines are a depth 1 thing' (actually
depth 0).

> On the other hand I learned at one time that "member of collection" means
> "normal" and collection members.

Read this sentence a couple of times, but couldn't figure it out.

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

It is an important part of baselines that they represent the deep versioned
state of a collection.  Baselines are 'prerequisite dependencies' on the
baseline.

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

There you go, that simple definition is a good reason for the term!

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

Subbaselines are just baselines.  All the characteristics (and no more) of
a baseline are true 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.

Yep, though most people would implement a single baseline as deltas too.
But your observation is valid.

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

Again, subbaselines are baselines.  This MAY clause is because there are
(heavy?) semantics for changing the value of the DAV:subbaseline-set, i.e.,
ensuring that there is only once VCR per history in the resulting
combo-baseline.

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

Making this one property optionally mutable does make 'the whole
subbaseline stuff optional'.


Tim

Received on Sunday, 18 February 2001 10:23:27 UTC