 | The Two Branch Model
The parallel production and development branch model has
come
about from requests by several organisational Aegis
users.
They would like a production branch which only ever had
bug fixes on it. They want
the
bug fixes, but they don't want (are wary of) things like
refactoring, deep feature enhancements, etc, until
“someone else” has tried them out.
-
Bug fixes will be done in
the
development branch, and then “back ported” to
the
production branch if there is a request for it,
preferably after
early adopters (that is, development branch users) have
been
using it for a while. This may be non-trivial in the
face of
some refactorings.
-
Build problems will fixed on the production branch, and
then
automatically “back ported” to the production
branch, if the production branch also suffers from them.
The idea is that users and sites who want predictability
can
have it, and still apply bug
fix
patches with a high degree of confidence, and have no
obligation
to add “unverified” new functionality to get
them.
|
 | Development Branch Activities
-
The development branch will be used for the first cut
of all
bug fixes.
-
The development branch will be used for all
refactoring,
e.g. turning project_ty from a struct
to a
true C++ class, ditto change_ty, etc,
and
turning all the “OO done manually in C”
stuff
into true C++ class hierarchies.
-
New functionality will first be added to the
development
branch. This would not be back ported to the
production
branch without requests from production branch users,
and
probably indicates the need for a new release
(i.e.
finish production branch, merge into development
branch,
finish development branch, release, start new
production
branch, start new development branch) rather than a
back
port.
-
Any significant “surgery to the innermost
functionality of Aegis” will be performed on
the
development branch. This would include stuff like
fixing
O(n²) performance issues. Deep surgery also
includes some
of the deeper refactorings of significant data
structures,
change as change_ty which is at the heart of
everything.
By having the bleeding edge tarball available on the
development
web site, folks not using aedist --replay will
still be
able to participate. Caveat emptor, of course.
|

|
Reporting Bugs
If you have found a bug in Aegis, please use the SourceForge trackers to submit your bug
report.
|

|
Documentation
There is extensive documentation
available for Aegis, including
|

|
Getting Started
There are a number of resources available for you:
- There is a worked example of the first few change sets of a new
project in the User Guide.
- There are some Template
Projects which can be downloaded and unpacked using
one of Aegis' distributed development mechanisms,
resulting in immediately working projects managed by
Aegis.
-
OSS developers will be intersted in the
simple GNU auto tools example. If your project uses
a simple GNU Auto Tools configuration, this example has
instructions to quickly get your project working under
Aegis.
|

|
Distributed Development
-
The Geographically Distributed Development chapter
of the User Guide describes
how to use the aedist(1) command to send and receive change
sets.
-
Both of the aepatch(1) and aetar(1) commands may also be used to send and
receive change sets. See the Reference Manual for their
man(1) pages.
-
The Working in Teams section of the How To describes a number of ways to
distribute projects.
- The Template
Projects provide a simple way to get a project
started quickly and easily. They are implemented using
one of Aegis' distributed development methods.
- The
feed demonstrates how developers
can
know when remote change sets are available. This
particular
link is for Aegis itself, but this mechanism is available
for
your Aegis projects, too, if you choose to turn it on.
|

|
Download
- The Download
page has links to the download files.
-
The BUILDING file in the tarball contains instructions
for building Aegis, or you could use the nicely formatted
Building section of the Reference
Manual.
-
A number of distributions include Aegis, so it may be
possible
to download a pre-built binary.
-
There are problems using Aegis on
Windows NT due to a dissonance in security models
between
Unix and Windows NT. However, it is possible to build a
single
user version using Cygwin, see the
Windows NT page for more information.
|

|
Getting Help
- There is an aegis-users mailing
list, see the Mailing List
page for details.
- The How To may also be
of assistance.
-
The User Guide explains the
model of software development implemented by Aegis.
-
If you have found a bug, please
use the SourceForge trackers to submit your bug
report.
|

|
Reference Sites
|

|
GUI Interfaces
There are several projects which are aimed at providing this.
-
Ages
is a
GNOME-based front end to Aegis. It provides a
comfortable way to
access the most common used functions available from
Aegis.
- AdvantAegis
(download it here)
is a Graphical User Interface (GUI) to Aegis.
AdvantAegis is written in wxPython (python with
bindings).
- There are some Tcl/Tk scripts in the Aegis
source distribution. They cover common activities such
as creating and managing change sets. See tkaenc(1) and tkaeca(1) in the Reference Manual for more
information.
-
The aexver(1) command provides a GUI interface
for selecting two versions of a file to be differenced.
- There is also the Aegis Web Interface for many tasks
which mine Aegis' extensive meta-data.
|