  | 
    
        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.
        
  
        
 
      |