cl@dlhpedg.co.uk (Charles Lambert) (12/15/87)
We have been developing tools and procedures (for use within our organisation)
to control those periods of intense development when many people are working
on a product at once, several of them perhaps altering the same source file
concurrently for different reasons. Now I have to produce documents and I
need good terms to make the concepts clear and easy to discuss. The
vocabulary that has grown up around the prototype is rather inconsistent
and misleading.
In my experience, well chosen terms improve people's comprehension of a
system dramatically, while fuzzy ones litter the mind with misconceptions.
So I hope that some of the technically literate out there will help me.
Let me outline what we have and ask anyone with constructive suggestions
to mail them to me.
ORGANISATION
------------
Division
--------
The development community is divided into teams, each working on some
functional aspect of the same product. There's the first slippery term:
"product". It can mean either the final absolute object, or that object
and all the components (e.g. source files) from which it is built.
There is a hierarchy (tree, structure) of directories that will contain this
product (i.e. all the components and the final object).
There is one public copy of the above hierarchy that is fully populated;
it contains a copy of every component, each one being the correct version
to build the latest stable version of the product.
Each development team has a private instance of the directory hierarchy
in which they keep copies of the components they have altered. They do
not keep copies of components they have not altered; the building tool
is capable of finding those in the public copy. The private instance
is said to be sparsely populated.
Here we need a term for an instance of the directory hierarchy, so that we
can talk about "our ***," "your ****," or "the public ***". At the moment,
we call it a "build", after the mechanical engineering term referring to a
schedule of components. This is a bad term because
i) it is a verb doing service for a noun,
ii) we need the verb anyway ("which build did you build?"),
iii) it is not evocative - it doesn't portray what it means.
Relation
--------
Now an extra degree of complexity. Besides the public "build" and the
"builds" assigned to each functional task, a group of teams may share
an intermediate "build" where they deposit finished work that they all
want to incorporate, but is not for general release yet. So, when one
of the teams builds the product, the building tool must search a vector
of "builds" starting with the team's private one, then the shared one
and finally the public one. We have called this vector a "view" (with
acknowledgements to Erickson and Pellegrin of Bell Labs [1]).
Some of our developers have taken to referring to a "build" as a "view"
because:
i) the view is an invariant attribute of the "build" - in our
system, once you have declared the antecedence of the version
you're working on you stay with it;
ii) it rather neatly describes what a "build" is for - it is a place
from which you get an alternative view of the product.
However, we need separate terms to differentiate between an individual
"build" and the ordered summation of several "builds"; I think "view"
serves the latter purpose best.
[By the way: we rejected the term "node", as an alternative to "build",
because of its strong association with network topology and hence with
communications]
You will see that "views" converge from team "builds" through shared
"builds" to the public "build". We might use the term "branch" instead
of "build", but we would risk confusion with the terminology of the
Source Code Control System that maintains a history of changes for each
source file.
OPERATIONS
----------
Distribution
------------
When a development team needs to alter a component, they take a copy from
the first "build" in the view that contains a version of that component;
it may be copied from a shared "build" if a cooperating team has already
altered it, or it may be copied from the public build. After they have
started work on their copy, someone may alter the version from which
they started - their "antecedent" version. Eventually, the team must
combine that alteration with their own so that a unified version of the
file can be deposited in the shared or public "build".
We have called this operation "reconciliation"; clumsy - any offers?
Integration
-----------
When a team completes a functional development, it deposits the completed
work further down the view, where cooperating teams will see it. This
may involve combining their new version of a component with another version
that is already there. This is called "integration". It may appear to
be the same as reconciliation but there is an important distinction:
"reconciliation" takes place in the reconciler's "build" - several
"builds" may be "reconciled" with changes that have gone into a shared one
but the reconciled versions remain private and different from one another;
"integration" takes place further down the integrator's view where it
come within other views (and may cause other "builds" to need reconciliation).
REFERENCES
----------
[1] "Build - A Software Construction Tool" V. B. Erickson and J. F. Pellegrin;
AT&T Bell Laboratories Technical Journal, Vol. 63 No. 6 (July-August 1984)
pp. 1049-1059
-------------------------------------------------------------------------------
DISCLAIMER: The above article represents my own opinions, observations
and conclusions; they are not necessarily the opinions, observations
or conclusions of my employer, Data Logic Ltd.
--------------------
Charles Lambert; ukc!datlog!dlhpedg!clg-rh@cca.CCA.COM (Richard Harter) (12/17/87)
I will just mention that we (Software Maintenance and Development Systems) sell a software system for managing development control in complex environments by way of background. The terminology problem is messy. Different people use different nomenclature. We use the term "justification" instead of "reconciliation", as in adjusting one change to fit another. The term is no better; either will do. We don't have a good term for the set of directories and files that occur in a development effort. We call it a "development environment" which is clumsy and misleading. The other term used is a "work project". However "build" and "view" have their problems too. A "build", as a noun, is the result of doing a build operation. It is the result of a build operation in the "work project". "View" is plausible; however it implies that the view of the software is an invariant of the "work project". This need not be true, and using the term "view" will put blinkers on you. Instead of product, you may want to use the term configuration, which is fairly standard, as in configuration control. A configuration is a description a collection of pieces and their relationships, including the versions of each piece. A good, but long winded, term for the directories, files, etc is a "configuration change environment" or CCE for short. I like the term "view". We use the term "version" instead. However in our system all versions are explicitly versions of the entire body of software being managed. When you specify a particular 'version' you automatically specify the entire view of the software. This all makes sense, but it confuses people who are accustomed to thinking of versions only in terms of individual files. The terms "migration" and "change migration" are fairly standard for moving "configuration changes" (itself a standard term) from one configuration to another. Migration is a part of integration; however integration usually refers to the cycle of building, testing, and justification that is implicit in folding in changes. Your system seems to have the multiple level concept for which we also don't have a good term. In a multiple level system there are several levels of official versions, corresponding to how 'official' a change is. It is useful to distinguish between static and dynamic 'views'. A static view is one which is frozen, e.g release 5.2 of the foobar system. A dynamic (plastic) view is one which changes over time, e.g the latest version of the foobar system. In general it is best if dynamic views have a fixed meaning associated with them. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.