Re: Edgar`s comments to 12.1

   From: Edgar@EdgarSchwarz.de

   I agree to the the sentiment somebody raised that DELTA-V is rather
   complex. So I also would like to see a companion document (E.g. the
   FAQ mentioned in a recent posting).  Variants e.g. would need an
   entry there in the context of solving the "meaningful URL" scenario
   discussed in the mailing list.

Will do.  If you can add these as "questions" in the auto-faq that
was recently put up on the deltav site, that would be great, and
I'll get "answers" posted.

   Now my model and scenario for an application. I tried to make the
   example it as small as possible but still meaningful enough.

   The complete application has several variants. So a variant
   consists of of common and special components, where a component is
   defined by the members (not shown below) of a collection.

The versioning protocol uses the term "configuration" for what
you are calling a "component".  So if you want to track "configuration
versions" (i.e. "baselines"), you would put the appropriate
collections under baseline control.  In the deltav, we use the
term "variant" for a set of version-controlled resources whose names
are chosen by the server, whereas in your example below, your
variants (app/sun and app/win) have been named by the client,
so to avoid confusion with the deltav use of the term, it's best
not to use the term "variant" to describe them.

   Now let's have a look at the version history world and the newest
   version of the component.

To avoid any misunderstanding, DeltaV would say "the newest baseline
of the baseline-controlled collection".

   Remember that the hierarchy of the version histories doesn't imply
   that a baseline (what I would have called just a version) of a
   collection belongs to a baseline of a parent collection.
   This relation could probably be realized by a subbaseline.

Actually, what you have below is what deltav would call a hierarchy of
"version-controlled resources" ... the version histories have
random server assigned (non-human-meaningful) names.

But I agree that the version-controlled resource hierarchy does not
imply that a baseline of a baseline-controlled collection "belongs" to
a baseline of a parent baseline-controlled collection, and I also
agree that this relation is realized by the subbaseline relation.

   For components I added a version number.

   app#1 
	   doc
		   common#1
		   sun#1
		   win#1
	   gui
		   sun#1
		   win#1
	   code
		   common#1
		   sun#1
		   win#1
	   sun#1
	   win#1

The versioning protocol would call this a version-controlled resource
hierarchy, with baseline-controlled collections annotated by the
DAV:checked-out baseline of their version-controlled configuration.

   For the complete project with all components I say:

	    app#1 = app/sun#1,app/win#1

Which is to say, baseline "app#1" has subbaselines "app/sun#1" and
"app/win#1".

   The variants would be defined like this:
	   app/win#1 = app/doc/common#1,app/doc/win#1,app/gui/win#1,
                       app/code/common#1,app/code/win#1
	   app/sun#1 = app/doc/common#1,app/doc/sun#1,app/gui/sun#1,
                       app/code/common#1,app/code/sun#1

I.e. the baselines app/win#1 and app/sun#1 have the specified
subbaselines.

   Now somebody wants to work on the win part of the stuff (needs more
   bugfixes than SUN I guess :-).  He is creating a workspace containing
   the stuff he needs (Mapping collections to the workspace according
   to developers taste. This feature avoids lenghty discussions on
   code structuring :-).

As a side note, having the developers making up names for the
components would make me worry about breakage of the inter-component
#include and Makefile references, but maybe I just worry too much (:-).

   winbugws
	   doc
		   common (app/doc/common)
		   win (app/doc/win)
	   gui (app/gui/win)
	   code
		   common (app/code/common)
		   win (app/code/win)
	   app (app/win)

So the developer has created a workspace called "winbugws",
and has put the winbugws/doc/comm, winbugws/doc/win,
winbugws/gui, winbugws/code/common, winbugws/code/win,
and winbugws/app collections under baseline control,
using the DAV:checked-in baseline from the specified
baseline-controlled collections in the "team" tree of
version-controlled resources described above.

   Suppose he changes some stuff in the win gui. This will mean there
   is a app/gui/win#2.

So that must mean he made changes in winbugws/gui, checked out the
version-controlled configuration of winbugws/gui, and then checked
it back in to create the new baseline (i.e. app/gui/win#2).

  Now he would create an new win baseline:

	   app/win#2 = app/doc/common#1,app/doc/win#1,app/gui/win#2,
                       app/code/common#1,app/code/win#1

So that meant that he checked out the version-controlled configuration
of winbugws/app, PROPPATCH'ed its DAV:subbaseline property to replace
app/gui/win#1 with app/gui/win#2, and then checked
it back in to create the new baseline, app/win#2.

   If somebody creates a new baseline of the complete project later
   only the win version number needs updating:

	   app#2 = app/sun#1,app/win#2

Which means that he checked out the version controlled configuration
of app, and PROPPATCH'ed its DAV:subbaseline property to replace
app/win#1 with app/win#2, and then checked it back in to create
the baseline app#2.

   That describes in short what I built with RCS and Unix scripts. The
   implementation isn't very efficient and restricted to one site. But
   the concept worked for a couple of thousand files, some dozens of
   developers and a lot of variants over a couple of years.

Looks fine to me.

   I guess I can realize this concept with DELTA-V following the way
   Geoff described in an earlier reply. Geoff, perhaps you could add
   this scenario and it's tranlation to DELTA-V to the FAQ document ?
   Just a question. Sorry, that I want you to do additional work but
   you are the person who could do it best I think.

This scenario is probably better located in the "scenario's" document
rather than the FAQ, but I agree that this is a good scenario to
document.

   Now finally some comments to the draft:

   As I understand it at the moment subbaselines are very important to
   port my model to DELTA-V.  So I'm not happy to read in 10.2.2: "A
   server that supports the baseline option MAY choose to not support
   the DAV:subbaseline-set property". I would like to drop this
   sentence or at least change "MAY choose to not support" to "SHOULD
   support".

Practically speaking, there isn't much difference between "MAY choose
to not support" and "SHOULD support", but I'd be happy to make this
change if nobody objects.

Does anybody object?

   So the question is, do others also think my model makes sense and
   should be available to clients if the server supports baselines ?
   Or are subbaselines a heavy burden on servers or server writers, so
   they want to avoid them ?

I don't think anyone disagrees with the concept of a sub-baseline.
But I believe that there are a number of versioning systems that support
baselines but that do not (yet) support sub-baselines, and so a client
needs to be prepared for that situation (producing efficient, reliable,
scalable subbaseline support is actually not that easy).

   1.3.1 Configuration

   "Note that a collection (which is a single resource) is very
   different from a configuration (which is a set of resources)" In
   "Collection Resource" you state that "A collection ... consists of
   ..., a set of named bindings ... . Note that a binding is not a
   resource ...". Nevertheless this set of binding logically is
   equivalent to a set of resources.

I disagree.  Suppose we're at a family reunion and I ask you to give
my grandmother a ride home.  She has "bindings" to all of her
children.  Giving just my grandmother a ride home is very different
from giving her, her four children, and her 28 grand-children a ride
home (:-).

   So I'm not sure I see the big
   difference between collection and configuration.

The difference is critical when apply an operation.  Basically,
it's the difference between a "Depth:0" operation and a "Depth:infinity"
operation.  In versioning, this is the difference between a
"version" and a "baseline" of a collection.

   10 Baseline Option

   "... A Configuration that contains a large number of resources can
   consume a large amount of space. This can make it prohibitively
   expensive to remember the state of an existing configuration by
   creating a copy of it's root collection.  A 'Baseline' is ..."  It
   doesn't sound good to me to create a new term based on assuming a
   dumb implementation (Naively creating a copy).  Why not just use a
   "version of a collection"?

This was just intended to provide motivation for why you need a
"version" of a collection at all.  Some reasons for distinguishing
between a (depth:0) version of a collection and a (depth:infinity)
baseline of a collection are given in the version-controlled
collection section.

   Efficient implementation is the task of the implementation, not the
   protocol.

But it is the task of the protocol to allow for efficient
implementations, and to allow for a variety of implementations.

   So my main problem left with the latest draft is that I see two
   similar concepts: Configurations and Baselines to capture their
   state versus Version-Controlled-Collections and their versions.

Yes, it's the difference between capturing the Depth:infinity state of
a collection and the Depth:0 state of a collection.

   I admit that there are differences but nevertheless my feeling is
   that these two concepts should be merged somehow.  I fear they will
   confuse future users of DELTA-V. So at least I would like to have
   the rationale to make them different made clear in the
   aforementioned FAQ.

Fair enough.

   Another alternative perhaps would be 12. You describe some reasons
   for version controlled collections (Mentioning activities,
   workspaces and merging. So it seems there is some entanglement
   between options. Which probably is unavoidable I fear). Could you
   also mention the difference to configurations and baselines here ?

That's a good suggestion.  I'll see if I can reword section 12
to make that point there.

Cheers,
Geoff

Received on Monday, 29 January 2001 15:53:54 UTC