mdhender/aegis

put

Aegis is distributed under the terms of the GNU General Public
License.  See the LICENSE section, below, for more details.

aegis (ee.j.iz) n., a protection, a defense.
Many CASE systems attempt to provide everything, from bubble charts to
source control to compilers.  Users are trapped with the components
supplied by the CASE system, and if you don't like one of the
components (it may be too limited, for instance), then that is just
tough.

In contrast, UNIX provides many components of a CASE system -
compilers, editors, dependency maintenance tools (such as make),
source control tools (such as RCS).  You may substitute the tool of
your choice if you don't like the ones supplied with the system - gcc,
jove, cake, to name just a few.  Aegis adds to this list with software
configuration management, and true to UNIX philosophy, Aegis does not
dictate the choice of any of the other tools (although it may stretch
them to their limits).

Enough hype, what is it that Aegis does?  Just what is software
configuration management?  This question is sufficiently broad as to
require a book in answer.  In essence, Aegis is a project change
supervisor.  It provides a framework within which a team of developers
may work on many changes to a program independently, and Aegis
coordinates integrating these changes back into the master source of
the program, with as little disruption as possible.  Resolution of
contention for source files, a major headache for any project with
more than one developer, is one of Aegis' major functions.

It should be noted that Aegis is a developer's tool, in the same sense
as make or RCS are developer's tools.  It is not a manager's tool - it
does not provide progress tracking or manage work allocation.
Aegis uses a particular model of the development of software projects.
This model has a master source (or baseline) of a project, and a team
of developers creating changes to be made to this baseline.  When a
change is complete, it is integrated with the baseline, to become the
new baseline.  Each change must be atomic and self-contained, no
change is allowed to cause the baseline to cease to work.  "Working"
is defined as passing it's own tests.  The tests are considered part
of the baseline.  Aegis provides support for the developer so that an
entire copy of the baseline need not be taken to change a few files,
only those files which are to be changed need to be copied.

In order to ensure that changes are unable to cause the baseline to
cease to work, Aegis mandates that changes be accompanied by at least
one test, and that all such tests be known to complete successfully.
These steadily accumulated tests form an ever increasing regression
test suite for all later changes.  There is also a mandatory review
stage for each change to the baseline.  While these requirements may
be relaxed per-change or even per-project, doing so potentially
compromises the "working" definition of the baseline.

The win in using Aegis is that there are O(n) interactions between
developers and the baseline.  Contrast this with a master source which
is being edited directly by the developers - there are O(n!)
interactions between developers - this makes adding "just one more"
developer a potential disaster.

Another win is that the project baseline always works.  Always having
a working baseline means that a version is always available for
demonstrations, or those "pre-release snapshots" we are always forced
to provide.

The above advantages are all very well - for management types.  Why
should Joe Average Programmer use Aegis?  Recall that RCS provides
file locking, but only for one file at a time.  Aegis provides the
file locking, atomically, for the set of files in the change.  Recall
also that RCS locks the file the instant you start editing it.  This
makes popular files a project bottleneck.  Aegis allows concurrent
editing, and a resolution mechanism just before the change must be
integrated, meaning fewer delays for J.A.Programmer.

Aegis also has strong support for geographically distributed
development.  It supports both push and pull models, and many
distribution topologies.  Aegis' normal development process is used to
validate received change sets before committing them.
    URL:    http://miller.emu.id.au/pmiller/
    File:   aegis.html      # the Aegis page
    File:   aegis.4.25.README   # Description, from tar file
    File:   aegis.4.25.lsm      # Description, in LSM format
    File:   aegis.4.25.ae       # the complete source, aedist format
    File:   aegis.4.25.spec     # RedHat package specification
    File:   aegis.4.25.tar.gz   # the complete source

This directory also contains a few other pieces of software written by
me.  Some are referred to in the Aegis documentation.  Please have a
look if you are interested.
Aegis is also carried by metalab.unc.edu in its Linux archives.  You
will be able to find Aegis on any of its mirrors.

    URL:    ftp://metalab.unc.edu/pub/Linux/devel/vc/
    File:   aegis.4.25.README   # Description, from tar file
    File:   aegis.4.25.lsm      # Description, in LSM format
    File:   aegis.4.25.spec     # RedHat package specification
    File:   aegis.4.25.ae       # the complete source, aedist format
    File:   aegis.4.25.tar.gz   # the complete source
This site is extensively mirrored around the world, so look for a copy
near you (you will get much better response).
The address of the mailing list is
    aegis-users@auug.org.au
Please DO NOT attempt to subscribe by sending email to this address.
It is for content only.
Since that company decided to close down our section (the company was
under attack by a hostile takeover bid) we all moved on simultaneously
(all 60 of us), sometimes working together, and sometimes not, but
always keeping in touch.  With suggestions and conversations with some
of them early in 1990, the manual entries for Aegis took shape, and
formed most of the design document for Aegis.

Since getting the first glimmerings of a functional Aegis late in 1990
it is increasingly obvious that I never want to be without it ever
again.  All of my sources that I modify are instantly placed under
Aegis, as is anything I distribute.  All code I write for myself, and
all new code I write for my employer, goes under Aegis.  Why?  Because
it has fewer bugs!

Example: one of the sources I carry with me from job to job is "cook",
my dependency maintenance tool.  Cook had existed for 3 years before
Aegis appeared on the scene, and I used it daily.  When I placed cook
under Aegis, I found 6 bugs!  Since then I have found a few more.  Not
only are there now fewer bugs, but they never come back, because the
regression test suite always grows.
Compounding this is the fact that many sites want to develop their
software for both Unix and Windows NT simultaneously.  This means that
the security of the repository needs to be guaranteed to be handled in
the same way by both operating systems, otherwise one can act as a
"back door" into the repository.  Many sites do not have the same
users and permissions (sourced from the same network register of
users) on both Unix and Windows NT, making the mapping almost
impossible even if the security models did actually correspond.

Most sites using Aegis and Windows NT together do so by running Aegis
on the Unix systems, but building and testing on the NT systems.  The
work areas and repository are accessed via Samba or NFS.
Aegis is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

It should be in the LICENSE file included in this distribution.  The
full test of the OpenSSL exception should be in the LICENSE.openssl
file included in this distribution.

mdhender / aegis

readme