.\"
.\" aegis - project change supervisor
.\" Copyright (C) 2004, 2005 Peter Miller;
.\" All rights reserved.
.\"
.\" 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 2 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, write to the Free Software
.\" Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, USA.
.\"
.\" MANIFEST: input for archive/features.html
.\"
.de an-p-footer
..
.ad l
.hy 0
.so version.so
.br
.br
.br
Aegis Features
Aegis \*(v) Features
.br
Here is a quick list of the key features of Aegis:
All operations on the repository are based on change sets.
True configurations. All changes are reproducable snapshots. Every
change set has a unique configuration identifier.
Ability to rename files without losing their history.
Binary files are supported.
File meta-data are versioned. Aegis versions not only file contents and
file existence, but also the `execute' permission flag on files and file
attributes. Users can attach arbitrary meta-data ("attributes") to any
file.
Commits are truly atomic. No part of a commit takes effect until the
entire commit has succeeded. Log messages are attached to the change set,
not stored redundantly in each file.
Access controls on lines of development (branches).
Creating a branch in Aegis can be accomplished with a single, fast command.
.\"
.\" End-to-end integrity controls. If a server has a bad file, or a
.\" replicating server actively attempts to replace the proper content,
.\" the end user can detect the error or substitution.
Optimal performance for all users, local or remote, beuase there isn't
any difference. Repository syncgronization means all developers, local
or remote, get optimal performance.
Disconnected commits. Have you ever screwed up a code base on an
airplane or a vacation and wished you could back out? Productivity
while traveling, at home, at remote offices with partial or slow network
connectivity.
Peer-to-peer architecture. Work may flow in any direction, including
"sideways" between two sites without involving a master site.
Costs are proportional to change size, not data size. In general, the
time required for an Aegis operation is proportional to the size of the
changes resulting from that operation, not to the absolute size
of the project in which the changes are taking place.
Aegis uses a collection of very simple on-disk formats for archives
and ancillary databases. It does not require or use a relational
database, hash-table database, or anything else that requires acolytes
and administrators. Consequently, creating a new project repository is
utterly trivial: a single Aegis command does it, basically by creating
some new directories.
.br
Below is a brief list of the features that most distinguish Aegis from
competing systems. This list presumes that you are somewhat familiar
with revision control systems in general.
.br
Whole Project Change sets: Atomic Commits and the handling of
Create, Modify, Rename and Remove
.br
Transactions in Aegis are perfomed on the whole project. For example,
let's suppose that you modify three files in order to fix a bug. When
you integrate this change, you integrate all three files at once. Aegis
records a new configuration that contains exactly the modifications to
those three files (relative to some earlier configuration).
Atomic, whole-project integrations are very convenient. To continue
the example: you could record the UUID of the new configuration or
the change set in your bug database as the revision that contains
the bug-fix. Or you could send the UUID of the change set to a
fellow-programmer, who can then merge exactly those changes and no
others into his own repository. A code reviewer can ask Aegis to
display exactly those changes in order to review your work.
Whole project change sets in Aegis correctly handle file and directory
additions, modification, removals, and renames. “Correctly
handle” means not only that such changes are recorded as part
of the change set, but also that you can merge changes back and forth
between versions that do and do not have those tree-structure changes,
and the merging process will take that into account.
.br
Meaningful Configuration Names
.br
Aegis assigns revisions meaningful confioguration names that are globally
unique among a community of Aegis users. Thus, it is always possible
to refer unambiguously to any given configuration, in any Aegis repository.
.br
Easy Branching
.br
Creating a branch in Aegis can be accomplished with a single, fast command.
.br
Simple On-disk Formats
.br
Aegis uses a collection of simple on-disk formats for file history and
meta-data. It does not require or use a relational database, hash-table
database, or object database.
Consequently, creating a new local archive is utterly trivial: a single
Aegis command does it, basically by creating some new directories.
.br
Lightweight, Standard Servers
.br
Remote archives do not require an Aegis specific server.
Your existing HTTP server can be used as a read-only Aegis server.
Email can be used to distribute change sets.
.br
Distributed Operation
.br
Creating a copy of a repository only requires a few simple commands,
all that is required is read-only access to the remote version.
For public and inter-organizational development projects, distributed
operation is an especially valuable feature: contributors can form and
publish their work on their own repository version of your mainline
sources -- without requiring that they have write access to your
archive. You can merge in their changes as easily as if they had been
committed to your own archives.
.br
It is trivial to set-up and incrementally update read-only mirrors of any Aegis
archive. A common pattern of use in public projects is to improve performance
by creating private local copies of remote archives.
.br