RE: Re (2): Definition of a configuration

   From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]

   "Clemm, Geoff" <gclemm@rational.com> wrote:

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

A discussion is always valuable, since it can clarify points of
confusion.  So I wasn't saying that we shouldn't discuss it, but
that it is too late to change it for the "proposed standard" draft.

   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 ?

Definitely, when we are going for next standard level (draft
standard).  That will be a good time to revise any terminology that
has proven to be confusing (such as the notorious "MOVE is
COPY/DELETE" statement in 2518 ... always fun to pick on that :-).

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

I meant that "you couldn't talk about a tree of non-version-controlled
resources as being a configuration".  It is common for an IDE these
days to rather misleadingly call such a configuration a "project", and
we definitely didn't want to adopt that term :-).

   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.

True, but you could "build" it, and could "deploy it", and could ask
"what are its interfaces" (i.e. the kinds of things you would do with
an IDE project).

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

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

Actually, a baseline is not a configuration, but it has a property,
DAV:baseline-collection, that does identify a configuration.  And
the DAV:baseline-collection always has a root collection (as does every
configuration).

   When you checkout a baseline to a root collection you can choose
   (nearly) any collection you want.

To be precise, you cannot "checkout a baseline to a root collection".
Perhaps you meant "when you apply BASELINE-CONTROL with an existing
baseline to a non-baseline-controlled collection"?  This creates a new
tree of version-controlled resources, corresponding to the members of
the baseline, but the root collection is treated pretty much like
any other member of the configuration.

   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.

Or you could say that the root collection is like the first line of
the document you are loading.  It is true that all the other lines
come after it, but it is just a line, like the other lines.  But I
certainly agree that the root collection of a configuration is
"special" (if nothing else, it merits its own term, "root collection").

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

I agree.  I just wanted to make sure folks understood that this kind
of change won't happen until we go to draft standard (I promised our
area director as much).

Cheers,
Geoff

Received on Monday, 29 October 2001 22:36:02 UTC