.\"
.\" aegis - project change supervisor
.\" Copyright (C) 1992-1999, 2004, 2006-2008, 2010, 2012 Peter Miller
.\"
.\" This program is free software; you can redistribute it and/or modify
.\" it under the terms of the GNU General Public License as published by
.\" the Free Software Foundation; either version 3 of the License, or
.\" (at your option) any later version.
.\"
.\" This program 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/>.
.\"
.bp
.nh 2 "Further Work"
.LP
The Aegis program is far from finished.
A number of features are known to be lacking.
.PP
At the date of this writing,
Aegis is being actively supported and improved.
.nh 3 "Code Coverage Tool"
.LP
It would be very helpful if a code coverage tool could be used
to analyze tests included with changes to ensure that the tests
actually exercised the lines of code changed in the change.
.LP
Another use of the code coverage tool would be to select regression tests
based on the object files recompiled by a change,
and those regression tests which exercise those files.
.LP
While there is freeware C code coverage tool available,
based on GNU C,
the interfacing and semantics still need more thought.
.LP
\fBNote:\fP A fairly good approximation is already available using the
\fI\-suggest\fP option of the \fIaet\fP(1) command.  It works on the
correlation of sources file versus tests in the various change sets.
See \fIaet\fP(1) for more information.
.nh 3 "Virtual File System"
.LP
There is almost sufficient information in the Aegis data base to create
a virtual file system, overlaying the development directory atop the
baseline\**.
.FS
Reminiscent of Sun's TFS,
but not the same.
Similar to AT&T's 3D\[hy]FS.
Similar to TeamNet.
Similar to ClearCase, but I wasn't thinking of the time\[hy]travel
aspects which they implement.
.FE
This could be implemented similarly to automounters,
intercepting file system operations by pretending to be an NFS server.
Many commercial CASE products provide such a facility.
.LP
Such a virtual file system has a number of advantages:
you don't need such a capable DMT, for starters;
it only needs the dynamic include dependencies,
and does not need a search path\**.
.FS
Discussed in the
.I "Dependency Maintenance Tool"
chapter.
.FE
Second,
many horrible and dumb compilers,
notably FORTRAN and "fourth" GLs,
don't have adequate include semantics;
overlaying the two directories make this much easier to deal with\**.
.FS
There are other ways,
discussed in the
.I "Tips and Traps"
chapter.
.FE
Many graphical tools,
such as bubble chart drawers, etc,
when they do actually have include files,
have no command line specifiable search path.
.LP
The disadvantage is that this adds significant complexity
to an already large program.
Also,
implementation is limited to NFS capable systems,
or would have to be rewritten for a variety of other systems.
The semantics of interactions between the daemon and other Aegis
commands, while clearly specifiable, are challenging to implement.
Performance could also be a significant factor.
.LP
The question is "is it really necessary?"
If the job can be done without it,
does the effort of writing such a beast result
in significant productivity gains?
.LP
The addition of the
.I create_symlinks_before_build
field to the project
configuration
file has greatly reduced the need for this functionality.
However, it does not provide
copy\[hy]on\[hy]write semantics,
nor automatic
.I aecp
functionality;
which a virtual file system could do.
.\" vim: set ts=8 sw=4 et :