Chapter 10. How to Become an Aegis Developer

Table of Contents

1. Required Software
2. Create The Aegis Project
3. The Download
4. The Bleeding Edge
5. Undiscovered Country
6. Sending Changes
7. Guidelines
7.1. What You Can Do
7.2. What You Can't Do
8. Coding Style
9. Writing Tests
10. Debugging
11. The To-Do List
11.1. aecvsserver
11.2. Geographically Distributed Development
11.3. Documentation
11.4. More Reports
11.5. Core Enhancements
11.6. GUI
11.7. Release and Build and Install
11.8. Database

This section describes how to become an Aegis developer, and gives some procedures, some ideas of areas which need work, and some general guidelines.

Please note: if these instructions have a problem, let someone know! If you are having a problem, so is the next guy. Please send all problem reports to Peter Miller <>

1. Required Software

There are a number of pieces of software you will need to work on Aegis.

  • It will probably come as no surprise that Aegis is developed using Aegis (never trust a skinny chef) so the first thing you need is to install Aegis and become familiar with using it. You will need Aegis 4.22 or later.

  • You will need a C++ compiler. If your compiler is installed in an uncommon directory or has an uncommon name, you can set the appropriate attribute by editing the aegis.conf.d/site.conf file.

  • You will need to install Cook, in order to build things. Version 2.8 or later, preferably you should track the latest release.

  • GNU Autoconf 2.53 or later. If your tools are installed in an uncommon directory or have an uncommon name, you can set the appropriate attribute by editing the aegis.conf.d/site.conf file.

  • GNU Automake.­pub/­gnu/­automake/

  • You will need to install FHist, for the history tool.

  • You will need to install tardy, for manipulating tarballs.­~millerp/­tardy.html

  • You will need to install ptx(1), for the permuted indexes in the documentation. This is now part of GNU coreutils.­pub/­gnu/­coreutils/

  • You need psutils for the psselect utility, to manipulate the documentation files, mostly to put the tables of contents at the start, rather than at the end as GNU Groff generates them.

  • You will need the developer libraries for the rx library (if you installed from the tarball, you have these, but if you installed from RPM, you need the -devel package as well).

  • You will need the developer libraries for the zlib library (if you installed from the tarball, you have these, but if you installed from RPM, you need the -devel package as well).

  • You will need the developer libraries for the libcurl library (if you installed from the tarball, you have these, but if you installed from RPM, you need the -devel package as well).

  • You need UUID generation capability. This requirement may be satisfied in several different ways depending of your development platform. First, on GNU/Linux you could skip this requirement provided that your kernel has support for /proc filesystem. Please note: in order to work /proc must be mounted and /proc/sys/kernel/random/uuid must be present. Second, you could install the developer libraries for the e2fsprogs package (if you installed from the tarball, you have these, but if you installed from RPM you need the -devel package as well). Third, you could install the UUID library from OSSP: Fourth, if your platform has support for an API compliant with DCE 1.1, Aegis also supports the DCE API.

  • You need to install Bison, the GNU replacement for Yacc.

  • You will need to install Flex, the GNU replacement for Lex.

  • You need to GNU Gettext (0.11.4 or later) tools installed. Even though Glibc 2.0 and later include Gettext, you need the developer tools as well. (You need GNU Gettext even on Solaris, because the Solaris Gettext implementation is... well... stuffed.)

  • You need GNU Ghostscript, for the ps2pdf utility, so that you can create PDF documents.

  • You need a uudecode with a -o option (to redirect the output). It is part of GNU Sharutils.

  • You need to install GNU awk.

  • You need a ctags(1) command with a -L option (to read file names from standard input).

  • You need RCS installed for the automated tests.

  • You need to install sudo(8). See etc/set-uid-root in the distribution for how to configure the /etc/sudoers file.

  • You need netpbm installed, for turning aegis.png into aegis.xpm because rpm(8) will only accept GIF or XPM icons.

  • The location box icon is generated using png2ico but the build can cope if you don't have it.

  • Probably more things I've forgotten.

2. Create The Aegis Project

The next thing to do is create an Aegis project to hold the Aegis source. This is done in the usual way. I suggest you create branches which match the current public release, e.g. it is 4.22 at present.

The best-practice technique of having a separate user account to mind the sources is recommended. The following commands should be run as that user, not your usual login. This prevents a variety of accidents which can happen when you are browsing the baseline (master source).

You could use the following command:

% aenpr aegis.4.22
aegis: project "aegis": created
aegis: project "aegis.4.22": created

but experienced Aegis users will know that this means a laborious setting of project attributes. It is easier to create the top-level project, set the attributes, and the create the branches, so that they inherit the attributes on creation.

% aenpr aegis -version -
aegis: project "aegis": created
% aepa -e -p aegis
edits the project attributes for single user,
or you may find tkaepa easier
% aena -p aegis you
aegis: user "you" is now a administrator
% aend -p aegis you
aegis: user "you" is now a developer
% aenrv -p aegis you
aegis: user "you" is now a reviewer
% aeni -p aegis you
aegis: user "you" is now an integrator

% aenbr -p aegis 4
aegis: project "aegis.4": created
% aenbr -p aegis.4 101
aegis: project "aegis.4.101": created


At this point, the rest of the commands in this chapter may (should!) be executed as “you,” your usual login account. When you added your normal account as an administrator just now, you authorized yourself to perform the necessary actions.

You will need about 120MB of free space to build and integrate Aegis changes, or more, depending on the changes you make and the size of your development directories.

The .forward file of the “aegis” user needs to be set to someone appropriate to read mail directed at the project.

You can now set the “aegis” user's password field to “*”. This effectively prevents the “aegis” user from logging in. Aegis is designed to make this unnecessary from now on.

3. The Download

The Aegis project is distributed in the form of an aedist(1) change set. The file to download is called­/ and can be grabbed using your favorite web browser, or wget(1).

The downloaded change set is applied using the following command

% aedist --receive \
	-f \
	-p aegis.4.22
...lots of output...

It is a good idea to give the project name on the command line, or aedist will try to use the project name it finds in the change set, and it probably wont find it if you are using different numbering to the chief maintainer's copy.

The aedist command will, in turn, issue a number of other commands. These are all normal Aegis commands you could issue yourself, if you were familiar with Aegis. It will, however, stop with a moderately alarming message:

Warning: This change contains files which could host a Trojan horse attack. You should review it before building it or testing it or completing development. This change remains in the being developed state.

This message comes because in order to build the project, you are going to have to execute a number of commands contained in the project aegis.conf file, and in the etc/Howto.cook file. For your own protection, aedist stops at this point. You may want to inspect these two files before continuing.

I really must get around to signing it with PGP. This would make the -notrojan option safe, because you could tell the file is direct from the chief maintainer, and thus as trustable as you think the chief maintainer happens to be.

In order to complete development of the change set, you must first build it...

% ae_p aegis.4.22
% aecd
% aeb will see commands which build the project...

Things that can go wrong...

  • There are checks to make sure that there is no white space on the ends of lines. If you use Emacs, you can add

    (add-hook 'write-file-hooks

    to have this done automagically. The same checks also verify that the text files are all printable, and that line lengths are 80 characters or less. Please don't disable the checks, it makes accepting your patches more time consuming.

  • Each change set has an architecture list associated with it. Initially you won't care, but Aegis does if you see the following error message: found 1 unlisted architecture, edit the change attributes to remove it or edit the project configuration file to add it You need to use the aeca -e command (not the tkaeca command). You will be placed into an editor (usually vi unless you have used Aegis before, and know how to configure it differently). You need to leave just about everything alone, except for the architecture specification. Change it from

    architecture =

    to something more meaningful on your machine. For PC users, this is almost always

    architecture =

    The alternatives may be found in the config in the current directory (search for architecture =). If you can't see a suitable choice, you may need to add one; the aepconf(5) man page has more information. Edit the config file to contain a suitable entry, and then use the aeca -e command to have the change agree with it.

  • If you don't have Cook installed, the build command (aeb) will fail.

  • If you don't have GNU Bison installed, the build will fail.

  • If you don't have GNU Gettext installed, the error message run-time binaries will not be built. This isn't an error, so you can keep going, but you'll get the shorter, cryptic form of the error messages.

  • Please note: if these instructions have a problem, let someone know! If you are having a problem, so is the next guy. Please send all problem reports to Peter Miller <>

Once the change builds, you need to difference it (this is a little redundant for this first command, but you'll see how useful it is later).

% aed will see commands which "diff" the project...

Things that can go wrong...

  • If you don't have the FHist package installed, the difference (aed) will fail. The fcomp command it is looking for is a whole-file context difference command (the GNU diff -c is a bit too terse for humans).

Now you will need to test the change. This is the basic test suite for Aegis, it ensures nothing is broken. It takes a while, go grab a cup of coffee.

% aet
...lots of output...

The change is now ready to end development.

% aede
aegis: project "aegis.4.22": change 10:
	development complete

The change set is now ready to be reviewed. In a single-person project like this one, you can review your own work. Obviously this is a conflict of interest, and larger projects are usually configured to have Aegis prevent this.

% aerpass -p aegis.4.22 -c 10
aegis: project "aegis.4.22": change 10:
	review pass

The change is now ready to be integrated. Only when integration is complete are the files actually committed to the repository.

% aeib -p aegis.4.22 -c 10
% aeb will see commands which build the project...
-rwsr-xr-x 1 root ... arch/bin/aegis
-rwsr-xr-x 1 root ... arch/bin/aeimport
Integrator: please do the following:
  sudo .../baseline/etc/set-uid-root arch aegis aeimport
  if they aren't root already.  See etc/set-uid-root for
  instructions for how to set-up your /etc/sudoers file.

This message at the end of the build is where Aegis is made set-uid-root in the repository. You want to do this, because you are going to symlink out of /usr/local/bin (or wherever you installed Aegis) right into the baseline. In this way, you will be executing your bleeding-edge version of Aegis, exercising it before you send it to anyone else. Hang on a bit, the sending part comes later.

Things that can go wrong...

  • If you don't have ps2pdf or psselect or ptx installed, it won't build the documentation (this isn't an error, just keep going).

  • If you don't have tardy(1) install, it won't build the tarball (this isn't an error, just keep going).

  • Please note: if these instructions have a problem, let someone know! If you are having a problem, so is the next guy. Please send all problem reports to Peter Miller <>

If all is OK, continue with the integration...

% aed will see commands which "diff" the project...
% aet && aet -bl
...lots of output...
% cd
% aeipass will see commands committing the files to fhist...
aegis: project "aegis.1.0": change 10:
	integrate pass

The “cd” command you see is actually important: you need to be out of the development directory and integration directory so that they can be cleaned up (deleted) when the change completes.

4. The Bleeding Edge

As I mentioned above, the next thing to do is create symbolic links out of /usr/local/bin into your Aegis baseline. The reason for doing this is so that you exercise your Aegis changes by using Aegis before you send them to anyone else. (Never trust a skinny chef.)

There is a shell script called ae-symlinks in the baseline $arch/bin direcdtory. Use it like this:

$ aecd -bl
# su
# linux-i486/bin/ae-symlinks aegis.4.22
# exit

The linux-i486 may need to be replaced with the output of the aesub -bl '$arch' command if you are using something more interesting than a PC.

5. Undiscovered Country

If you got this far, your local Aegis project is ready for use.

It is strongly suggested that you complete the first change “as is” and perform your own customizations in later changes, rather than trying to get the project started and customize it at the same time.

The rest of this file describes how to perform various common changes to the example project.

6. Sending Changes

First, read the Distributed Development chapter of the User Guide.

When you have a change set you wish to have the other Aegis deveopers try, use a simple command such as:

aedist --send -p aegis.4.22 -c number | \
gpg --clearsign | \

or similar. (Or maybe aepatch(1) instead.) A suitable subject line would be very helpful.

7. Guidelines

7.1. What You Can Do

Write more documentation. There is a crying need for documentation of all sorts: better manual pages, more and better information in the User Guide, more and better HOWTOs. If you work out how to do something, and it isn't in the documentation, write some documentation and put it in a change set because other folks have probably missed it too.

Add more ease-of-use functionality. Stuff which makes the development process more efficient, or makes the information in the repository more accessible.

Extend the GUI. All of the commands which manipulate the change while in the being developed state are candidates. Some kind of wrapper that ties it all together would be good, too. User preferences, project attributes and creating projects are candidates, too.

Most new project configuration things belong in the project config file. Only add new project attributes (aepa -e) for things which (a) are catch 22 to change in a change set, or (b) allow a security abuse if in a change set (e.g. the notify commands, particularly aede), or (c) allow the repository to be damaged. (My thanks to Ralf Fassel <> 2 Feb 1999 for pointing this out.)

7.2. What You Can't Do

You can't change Aegis' semantics. Developers around the world, and their managers, rely on Aegis working just the way it does right now. You can't change things that will compromise their ability to get things done.

Particularly, Aegis has a strong security story. Availability, integrity and confidentiality, and all that. If you want it more flexible, that's good, but you can't change the defaults and you can't make it irretrievably weaker. (You can, as a non-default make it weaker, within limits.)

Aegis (the executable, not the whole package) is quite big enough. Don't add code to arch/bin/aegis than can be done with the report generator, or as a separate program like aesub or aefind. More GUI can be added using Tk/Tcl - unless you have grander plans and even then it still shouldn't be added to the set-uid-root executable.

8. Coding Style

Please try to emulate the existing coding style. (Indents recently changed from 8 to 4, not all of the code has caugh-up yet.) Lines are to be 80 charcters or less wide, no unprintable characters, no trailing white space.

Probably need a GNU Indent profile for code formatting, too.

9. Writing Tests

If you have fixed a bug you should write a test to verify the correct behaviour of Aegis. Because test file names are generated automatically starting from your repository state, it's possible that aet will create a test with the same name as one in the P.Miller repository. Because Aegis is not yet able to detect such situation, if you plan to send back your work to P.Miller you may want to modify your aegis.conf adding the following lines:

new_test_filename =
	"test/${zpad $hundred 2}/"
	"t${zpad $number 4}${left $type 1}-${left ${user login} 4}.sh";

In this way the possibility of a name collision should be reduced. Invoke aent:

% aent
aegis: appending log to "aegis.log"
aegis: user "walter", group "projadm"
aegis: rm -f etc/cook/change_filesf etc/cook/project_files
aegis: project "aegis.4.16.2": change 11: file "test/01/" new test

Now you can start to implement the test. Remember to invoke the programs under test as $bin/program.

  • In order to improve error messages you should organize your script as a sequence of activity and use the activity variable as sketched below:

    # create a new change
    activity="new change 163"
    cat > tmp << 'end'
    brief_description = "The first change";
    cause = internal_bug;
    if test $? -ne 0 ; then no_result; fi
    $bin/aegis -nc 1 -f tmp -p foo > log 2>&1
    if test $? -ne 0 ; then cat log; no_result; fi

    If you are reading this document, you probably don't need help to understand this code fragment, the only thing to note is that the number in the string (163) refer to the current line number and is used when printing a failure message. You don't need to maintain it by hand as explained in the following step.

  • You can use test/ to automatically renumber the activity variables of your tests:

    $ sh test/

    If you have not modified test/ you should find it as bl/test/ or blbl/test/

10. Debugging

Aegis, as any other software, may contain undiscovered bugs. If you are interested in helping to fix these bugs, and as a developer you should be interested, the first thing to do is compiling Aegis in DEBUG mode. In order to do so you must modify common/main.h and uncomment the DEBUG define. (If you use the aecp -read-only option, Aegis will remind you to uncopy the file again before develop end, ensuring that you don't accidentally integrate this.)

In DEBUG mode the -Trace command line option is available for most Aegis commands. This option is followed by the names of the source files you want to trace, and may be used more than once.

If you need to add tracing capability to a file, you must first include trace.h, modify the code in order to use the trace facility (look at common/trace.h) then build the change with aeb and run the buggy command with the proper -Trace option.

On Linux >= 2.4 the aegis command, wich is set-uid-root, is enabled to dump core when needed. If this does not happen, remember to verify the ulimit(1) settings; you may need to execute the ulimit -c unlimited command.

11. The To-Do List

  • Add an additonal mode to aedist to query an aeget server for change set UUIDs and download and apply missing change sets. It needs to be able to be run by cron(8). Submitted: PMiller, 1-Jun-2004

11.1. aecvsserver

  • The aecvsserver needs to be extensively tested by users. Submitted: PMiller, 1-Jun-2004

  • Implement more of the CVS client commands which can be sent to the server, usually by saying "yes, bwana" and doing nothing. Submitted: PMiller, 1-Jun-2004

  • Implement a cvs commit against a project (at the moment this is not allowed because you have to use a "module" named after a change set) which will create a change set apply the changes and do everything to get to aede. Submitted: PMiller, 1-Jun-2004

  • Is it possible to use the same techinique to write an SVN server? Submitted: PMiller, 1-Jun-2004

  • Is it possible to use the same techinique to write an arch server? Submitted: PMiller, 1-Jun-2004

  • Arch has the concept (if not the implementation) of an SCM-neutral interchange format. Implement it. Submitted: PMiller, 23-Jan-2004

11.2. Geographically Distributed Development

  • The aedist -receive command needs to be enhanced to understand file attributes. Submitted: PMiller, 2-Jun-2004

  • The aepatch -receive command needs to be enhanced to understand file attributes. Submitted: PMiller, 2-Jun-2004

  • Enhance the aedist -receive command to understand incoming files with UUIDs. Submitted: PMiller, 1-Jun-2004

  • Enhance the aepatch -receive command to understand incoming files with UUIDs. Submitted: PMiller, 1-Jun-2004

  • Add an additonal mode to aedist to query an aeget server for change set UUIDs and download and apply missing change sets. It needs to be able to be run by cron(8). Submitted: PMiller, 1-Jun-2004

  • Enhance aedist to preserve change history (both send and receive will need work). Don't forget backwards compatibility. Submitted: Jerry Pendergraft, 2003

  • Enhance aedist -receive to leave changes in awaiting development or being developed if that's the state they were in at the origin. Submitted: Jerry Pendergraft, May-2004

  • Enhance aepatch -receive to run tests on changes which require it. Submitted: PMiller, 1-Jun-2004

  • Enhance aepatch to preserve change history (both send and receive will need work). Incoming patches with no meta-data obviously can't do this. Don't forget meta-data backwards compatibility. Submitted: PMiller, 1-Jun-2004

  • Enhance aepatch -receive to leave changes in being developed if that's the state they were in at the origin. Patches with no meta-data stay in being developed. Submitted: PMiller, 1-Jun-2004

  • Enhance aepatch and aedist to automagically sign (send) and verify (receive) the contents, using the (revolting) library from the gpgme project. This stupid library spawns an gpg(1) instance and talks to it; unlike a sensible library e.g. the zlib project; why on earth couldn't they take the common code from gpg and make a library of that? Submitted: PMiller, 1-Jun-2004

11.3. Documentation

  • Add a section to the branching chapter of the User Guide, describing how a developer may use a branch to temporarily waive the build command. After a series of changes on this branch, the build command is restored, and the branch development ended. This allows regular "non working" commits, without losing any of the strengths of the Aegis process. Submitted: 7-Mar-2000

  • The manual pages need to have an example(s) section added to make them clearer. This isn't just for beginners, infrequently used commands need examples even for sophisticated Aegis users.. Submitted: Geoff Soutter <>, 3 Mar 2000

  • Get tkdiff 3-way merge working with Aegis (see­free/­tkdiff/ for code). Submitted: 24-jan-2000

  • Add information to the History Tool chapter, describing how to use CVSup to access the RCS history tree. Submitted: 28-jan-2000

  • the RCS history commands in the aegis user guide all use the `-u' option for `ci' to check out a copy after registering/updating a file. However `ci -u' always does keyword expansion. To avoid this, we have omitted the -u, so the working file is gone after the `ci'. We check it out again using `co', this time with the `-ko' option to avoid keyword expansion. Note that the -ko option is always given to the `co' command, never to `ci' or `rcs'. Submitted: Ralf Fassel <>, 18 Jan 2000

  • * diff ; test $? -le 1 -> diff ; test $? -ne 1 means that unchanged files prevent aede!! (Only fly in the ointment is moving files - need to cope with this.) Submitted: Gus <> 28 Jul 1999

  • mention in the diff tool part of the User Guide, that you can mess with diff_command to exclude with binary files, or file with CR in them, or lines too long, etc. Submitted: PMiller, 28-jun-99

  • in the branching chapter, have a section about using sub-branches to turn build_command off (or to ignore exit status), and integrate lots of teensy tiny bug fixes, and then turn it on again. In the front, reference the branching chapter in “how to extend the Aegis process” Can mention extra review steps there, too. Submitted:, 22 Jun 1999

  • Document the build_time_adjust_notify_command in the DMT chapter of the User Guide. Update the example projects to use it. Update the config example to use it. Submitted: PMiller, 4-Apr-99

  • Mention binary files in the diff and merge section (may provide aebinfil command to help choose which behavior?) Submitted: PMiller, 31-mar-99

  • mention “rcs -ko” in the User Guide and put it into the examples AND also fhist keywords in the User Guide and put it into the examples. and make sure the examples all have hist_{put,create} the same. Subject: Ralf Fassel <>, 9 Mar 1999

  • worked example, “5.2.7 says that the cook file contains all of the above commands but my copy doesn't have them ...” [for config file and howto.cook file] BUT integration diffs not in the worked example. Submitted: Michael McCarty <>, 26-Feb-99

  • need discussion (Howto, or maybe the User Guide) of how to use Aegis when you site has a mix of Unix and Wintel. Submitted: Paolo Supino <>, 4 Feb 1999

  • add chapter to User Guide, saying how to config web interface and how to use it. Submitted: Graham Wheeler <>, 27 Jan 1999

  • User Guide: big changes bouncing: how to use a branch to get smaller reviews and smaller diffs. Submitted: Ralf Fassel <>, 27 Jan 1999

  • note for User Guide: metrics software form­pub/­software-eng/­software/­Cmetrics/

  • correct documentation of file locking in UG: correct the example around the file locking - it gives the wrong text of the aede error - and probably other stuff. also, the wrong person comes back from aerobics

11.4. More Reports

  • Add a -REVerse option, so that all of the listings (ael) come out in the reverse order to that used at present. Submitted: John Darrington <>, 20-Jul-2001

  • Write an aereport file to produce MS-Project views of a project, making sure that the states of each change are linked, use averages to predict any incomplete states. And maybe another to produce HTML pages of the same thing. Submitted: 15-Jan-2000

  • On the aeget(1) web pages, link the file edit numbers to pages which will retrieve the historical version. Submitted: Anoop Kulkarni <>, 22 Dec 1999

  • Add a user_change report (just like “ael user_changes”) which takes a user name, so you can get a list of changes by user. Make aeget(1) do this, too. Submitted: Ralf Fassel <>, 9 Dec 1999

  • Add a outstanding_changes report (just like “ael outstanding_changes”) which takes a user name, so you can get a list of outstanding changes by user. Make aeget(1) do this, too. Submitted: Ralf Fassel <>, 9 Dec 1999

  • Write a report which says when you have to do to get a change completed Jerry says he has written most of this. Submitted: 3-Nov-99

  • ael change_history - write as a report and then include project history for sub branches. Don't forget the web reports, too. Submitted:Jerry Pendergraft <>, 30 Aug 1999

  • ael outstanding_changes - rewrite as a report and then include sub branches. Don't forget the web reports, too. Submitted: Jerry Pendergraft <>, 30 Aug 1999

  • ael project_history - rewrite as a report and then include parents and sub branches. Don't forget the web reports, too. Submitted: Jerry Pendergraft <>, 30 Aug 1999

  • aer file_history - include parents and sub branches. Don't forget the web reports, too. Submitted: Jerry Pendergraft <> 30 Aug 1999

  • Some kind of web report which makes “train track” diagrams of file branching.

  • Some kind of web report which makes “train track” diagrams of project branching.

  • multivariate linear regression: needed as a report generator function: needed for metrics analysis

  • more blurb in the statistics web pages, so they are more self-explaining Submitted: Ralf Fassel <>, 13-Oct-98

  • Add anew report like “ael uc” except that it (optionally) takes a user name as well, to list a particular user's changes.

  • File Activity Report (web) does not translate user name and give email link. Should also put user name under change state, as in change lists.

11.5. Core Enhancements

  • Use the per-file attributes to record the encoding of the text (e.g. UTF-8) and the line termination. Provide a way (via the iconv(3) function? via recode(1) command?) to change the encoding. Submitted: PMiller, 23-Jun-2004

  • "I have determined that one reason [that aedeu is used in preference to aerfail] is the reviewer is afraid they don't understand the change and once explained they would not fail it. Now the fact that the description, comments etc did not do the job to explain the change is reason enough to fail it notwithstanding... They are saying if they had an aerfu command they would be willing to aerf changes. How difficult would that be?" Not very difficult at all. Provided, of course, that nothing has been changed in the mean time (and Aegis has everything it needs to check that). Submitted: Jerry Pendergraft, 23-Jun-2004

  • The project_file_roll_forward function needs to be enhanced to understand file UUIDs. Submitted: PMiller, 1-Jun-2004

  • Now the sources are all being compiled by a C++ cimpiler, convert the various OO portions of the code (inout_ty and its derived classes, output_ty, etc) to true C++. Need a style guide first, so other developers know how I want it done. See SRecord for examples until this is done. Submitted: PMiller, 1-Jun-2004

  • More doxygen comments in the header files. Submitted: PMiller, 23-Jan-2004

  • Add a "development directory style" configuration option. The current styles are "view path" and two types of "symlink farm", although this is well concealed by the code. Need to add a hard link (arch-ish) / copyfile (cvs-ish) style as well, but only for source files. The code which currently maintains the symlinks can be pressed into doing the extra work fairly easily. Submitted: PMiller, 1-Jun-2004

  • It would be nice to have a way to specify a timeout for aegis tests. If a single test does not finish within this time, it should be aborted and considered `No Result'. Then aet should continue with the next test (as appropriate if --persevere was given). A `--timeout' argument to `aet' would do the trick, and also a project config field. The implementation could be interesting, since signaling the forked aegis child process might not be enough to stop all processes (process groups?). Submitted: Ralf Fassel <>, 24-Jan-2001

  • Problem with aepa that doesn't specify the default values for all the test features in aeca (there are three types in aeca and only one in aepa). Submitted: Mark Veltzer <>, 16 Aug 2001

  • The aedist(1) program should send changes with no files, or changes in "being developed". Submitted: Mark Veltzer <>, 16 Aug 2001

  • Have aem merge changes properly if another changed moved the file in the baseline. You need to do this across the board, not just in aegis/aed.c Submitted: Ralf Fassel <>, 25 Feb 2000

  • Add progress (%) indicators (aeib was specific example, but there may be others e.g. symlink farms and aecp, even aede for big changes) for use by the GUI interfaces - and maybe the text interface too. Submitted: Ralf Fassel <> 10 Dec 1999

  • Extend the create_symlinks_before_build functionality to copy, not just symlink. Because they would edit the files direct, we then need an implicit aecpcorne detector. You need to look for other boundary conditions this is also going to affect. You need a remove_symlinks_after_build analogue, too. Submitted: Darrin Thompson <>, 15 Nov 1999

  • os.h is a system header on some systems, so os.h has to move Sumbitted: Christophe Broult <> 30 Sep 1999

  • aedist -rec needs to preserve (a) copyright years, (b) test exemptions (subject to permissions), and (c) architecture (if possible). AND CHANGE NUMBER? Submitted: Ewolt Wolters <>, 27 Jul 1999

  • Aedist to add project history to end of description when sending change set. Submitted: Jerry Pendergraft <>, Dec-2000

  • can we separate change creation from other administrator permissions? can we make "everyone" able to create changes? Submitted: Ewolt Wolters <>, 28 Jun 1999

  • should explicitly mention CPPFLAGS=-I/usr/local/include; export CPPFLAGS LDFLAGS=-L/usr/local/lib; export LDFLAGS in the configuring section. Submitted: John Huddleston <>, 19 Mar 1999

  • Using file attributes, add coupling between files to form file groups; this means when you aecp, you get the whole set of related files. Submitted: PMiller, 18-Feb-99

  • The aed command does not promote aenf->aecp unless the ,D file does not exist. This is annoying, should always do it. (So should some other commands.) Subject: Ralf Fassel <>, 1 Feb 1999

  • Add a default_regression_test_exemption project attribute. Submitted: Ralf Fassel <>, 31 Jan 1999, Jerry Pendergraft <>, 2 Feb 2001.

  • Need a clean_exceptions file in the project config file (list of strings) so can have local RCS dirs, and do "ci `aegis -l cf -ter`" in the develop_end_command Submitted: 1-Feb-99

  • aenpr -dir -keep: allow directory to already exist if has right owner and is empty? Submitted: Jerry Pendergraft <>, 22 Jan 1999

  • Add a new post_merge_command so can generate summary of files needing editing. Subject: Ralf Fassel <>, 21 Dec 1998

  • Create a new aepatch command: “aepatch -send” to create "ordinary" OpenSource source patches, and “aepatch -receive” to turn patches into an Aegis change - and not necessarily only patches generated with aepatch. Yes, intentionally similar to aedist.

  • integrate difference should look for missing ,D files (usually impossible) and re-instate them. Submitted: PMiller, 22-Sep-98

  • tests 7, 20, 70 warn symlink.c: In function `main': symlink.c:5: warning: return type of `main' is not `int' Submitted: Bruce Stephen Adams <>, 10 Sep 1998

  • change_set_env needs to set LINES and COLS

  • commands which accept -branch and/or -trunk should also accept -grandparent but not all do. check.

  • Add a --no-baseline-lock option to the aeb and aecp commands. Warn them not to in the manual pages.

  • list locks - need to spot the case where *all* of a set are taken (all 64k) and report sensibly (not 64K lines)

  • aemv does not correctly check the -to- filename. (specific example = file name length)

  • aefind needs a sort option

  • aefind needs the rest of the find functionality added

  • * Add a -output option to the aent command (others?) for scripting support.

  • aed - when auto upgrade create to modify, clear move if set.

  • aede needs to make sure that the files (and directories) are readable (and searchable) by reviewers.

  • make aemv rename files within a change

  • aecp -anticipate

  • Make the listing more specific for aecp aecpu aenfu aentu aerm aermu, etc

  • add a file copy notification command to the project config file

  • Add pseudo change do can do many integrations at once (this pseudo change would be created by aeib and destroyed by aeipass, aeifail or aeibu).

  • Version punctuation: at the moment you gets dots between the branch numbers. Need more flexible punctuation: especially, want a hyphen first, then dots (sometimes).

  • * aecp -delta bug “I've been making good use of the "-delta" option of aecp lately. But there has been a complication in its use. Let's say a file was aerm'ed in delta 100. Let's further say that we are at delta 175 and are trying to restore the source code as of delta 75. If I do a "aecp - delta 75 file.c" I'm told that file.c is no longer part of the project.” Should aecp -del fake aenf for deleted files in earlier deltas? Submitted:

  • internationalize -interactive

  • Enhance aet to allow reviewers to run tests.

  • check library state files on project creation “I was creating a new release from a large project. After copying the baseline and creating hundreds of history files the aenrls failed because the library dir I specified wasn't writable by aegis and no state file was created. Couldn't this be checked first?” Submitted: Lloyd Fischer <>

  • Add precedence constraints: a list of prerequisite changes, which must all be in the “completed” state before the change may end development. Submitted: Christian F. Goetze <>

  • If there is a read error when reading the template source file during aent, get a stupid error within error message, and never tells you about the file

  • How about "include" support for the config file? That way one could also cover architecture specific things by “include ${libdir}/${project}.defs” in the config file. Submitted: Jerry Pendergraft <>, 7 Sep 2001

  • Add an aetouch command, to touch all of the (non-build) source files in the change. Submitted: 2001

  • Have the “aeclean -list” option say what aeclean would do, rather than list the change source files. Submitted: 2001

  • Have aed (aem) *remember* the previous state when it finds a problem (much like aet does, now). Submitted: Ralf Fassel <> 3-Mar-2002

11.5.1. More O(1) Scalability

  • Need to supplement the {project,change}_file_find and {project,change}_file_nth interfaces with {project,change}_file_name_nth interfaces. Then, use them as often as possible.

  • Need the fstate file to have a manifest field; access this for file names. Then, store each file into in a separate file; only access this file is file state is required.

  • The presence or absence of the manifest field in the top-level fstate file tells you if the old or new file state usage is present.

11.6. GUI

  • tkaeca barfs when there are no changes on the branch. should be more graceful. Submitted: Ewolt Wolters <>, 11 Aug 1999

  • using tkaegis: project > branch > role > integrate, a window pops up "Error in tcl script, Error: invalid command name """. Submitted: Ewolt Wolters <> 9 Aug 1999

  • user pasted in text (including back slash) into aeifail edit window. which was accepted, but broke change state (illegal escape sequence). Submitted: Michael McCarty <>, 10 May 1999

  • A new ${architecture_list} substitution to give all architectures in a command. Submitted:, 31 Mar 1999

  • have aedist -rec accept a -delta option, so you can tell it where to apply from. Anticipated use is “-delta 0” meaning start of branch. (also a -reg option). Submitted: PMiller, 22-mar-99

11.7. Release and Build and Install

  • add debian .deb file, add notification to <> for new releases. Submitted: PMiller, 22-Jun-99

  • building documentation needs to talk about libz some more. particularly, you either need it on ROOT's LD_LIBRARY_PATH or you need to static link it. Submitted: Ralf Fassel <> 5-Apr-99

  • have configure script whine about missing libz Submitted: PMiller, 7 Apr 99

  • have configure script whine about missing regcomp Submitted: PMiller, 7 Apr 99

  • Sample documentation needs to make the group thing obvious. And also the umask at aenpr time! Submitted: Alan Zimmerman <>, 5 Apr 1999

  • generated makefile CC=cc needs to quote cc in case has spaces Submitted: Aaron Johnson <>, 31 Mar 1999

  • The BUILDING file needs to mention that you should install zlib with --prefix=/usr because many systems think /usr/local/lib "insecure directory". Submitted: Fabien Campagne <campagne@Inka.MSSM.EDU>, 26 Mar 1999

  • add piece to BUILDING file saying to get Apache first. Submitted: Graham Wheeler <> 27 Jan 1999

11.8. Database

  • Write an ODBC interface to the database? Submitted: P. Miller, 16 Aug 2001

  • Does it make sense to have an NNTP interface? Would it be any use? Submitted: P. Miller, 16 Aug 2001