Chapter 1. Introduction

Table of Contents

1. Year 2000 Status
2. What does aegis do?
3. Why use aegis?
4. How to use this manual

Aegis is a CASE tool with a difference. In the spirit of the UNIX® Operating System,[1] Aegis is a small component designed to work with other programs.

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 tools (such as make), source control (such as SCCS). You may substitute the tool of your choice - gcc, jove, cake, rcs (to name a few) if you don't like the ones supplied with the system.

Aegis adds to this list with software configuration management (SCM), and consistent with Unix™ philosophy, Aegis does not dictate the choice of any of the other tools (although it may stretch them to their limits).

1. Year 2000 Status

Aegis does not suffer from Year 2000 problems.

  • Aegis stores dates internally in Unix style (i.e. seconds offset), so internal storage of times and dates does not suffer from any Y2K problems.

  • Aegis always uses the ANSI C standard strftime function to display times and dates. (This assumes that your vendor has supplied a compliant strftime.) This means that displaying dates does not assume fixed field widths, nor will it display the year 2000 as “100”.

  • There is no user-input of years at any time, so there is no issue surrounding “guessing” the century.

2. What does aegis do?

Just what is software configuration management? This question is sufficiently broad as to require a book in answer. In essence, the aegis program 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 the aegis program 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 the aegis program's major functions.

It should be noted that the aegis program 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 help with work allocation.

3. Why use aegis?

So why should you use the aegis program? The aegis program uses a particular model of the development of software projects. This model has a master source (or baseline) of a project, consisting of several (possibly several hundred) files, 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 its 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.

The win in using the aegis program 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 is 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 the aegis program? Recall that RCS provides file locking, but only for one file at a time. The aegis program provides the file locking, atomically, for the set of files in the change. Recall also that correct RCS usage locks the file the instant you start editing it. This makes popular files a project bottleneck. The aegis program allows concurrent editing, and a resolution mechanism just before the change must be integrated, meaning fewer delays for J.A.Programmer.

4. How to use this manual

This manual assumes the reader is already familiar with the Unix™ operating system, and with developing software using the Unix™ operating system and the tools available; terms such as RCS and SCCS and make are not explained.

There is also the assumption that the reader is familiar with the issues surrounding team development of software; coordination and multiple version issues, for example, are not explained.

This manual is broken into a number of sections.

Chapter 2

describes how aegis works and some of the reasoning behind the design and implementation of the aegis program. Look here for answers to "Why does it..." questions.

Chapter 3

is a worked example of how particular users interact with the aegis program. Look here for answers to "How do I..." questions.

Chapter 4

is a discussion of how aegis interacts with the History Tool, and provides templates and suggestions for history tools known to work with aegis.

Chapter 5

is a discussion of how aegis interacts with the Dependency Maintenance Tool (DMT), and provides templates and suggestions for DMTs known to work with aegis.

Chapter 6

is a discussion of how aegis interacts with the Difference Tools, and provides templates and suggestions for difference tools known to work with aegis.

Chapter 7

describes the project attributes and how the various parameters may be used for particular projects.

Chapter 8

describes managing tests and testing with Aegis.

Chapter 9

describes the branching mechanism used in Aegis.

Chapter 10

is a collection of helpful hints on how to use aegis effectively, based on real-world experience. This is of most use when initially placing projects under the supervision of the aegis program.

Chapter 11

describes how to manage geographically distributed development using Aegis.

Appendix A

is a quick reference for placing an existing project under aegis.

Appendix B

is a glossary of terms.

Appendix C

is a description of why Aegis must be set-uid-root, for system administrators who are concerned about the security issues.

Appendix D

is a brief look at internationalization and localization if Aegis.


Aegis is distributed under the terms and conditions of the GNU General Public License. Programs which are developed using Aegis are not automatically subject to the GNU GPL. Only programs which are derivative works based on GNU GPL code are automatically subject to the GNU GPL. We still encourage software authors to distribute their work under terms like those of the GNU GPL, but doing so is not required to use Aegis.

[1] UNIX® is a registered trademark of The Open Group. “Unix” is used in this manual to denote UNIX®-like operating systems.