|
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 from a struct to a
true C++ class, ditto change, 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.
|