Aegis
4.24
Features
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 reproducible
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.
- Repository
synchronization, geographically distributed development.
-
Optimal performance for all users, local or remote, because there
isn't any difference. Repository synchronization 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.
You can compare this list with
GNU
Arch
(Home), Bitkeeper
(Home), Monotone
(Monotone),
OpenCM
(Home), Subversion (Home). After more than
a decade, the better VC/SCM systems are starting to converge.
Features
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.
Whole Project Change sets: Atomic Commits and the handling of
Create, Modify, Rename and Remove
Transactions in Aegis are performed 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.
Meaningful Configuration Names
Aegis assigns revisions meaningful configuration 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.
Easy Branching
Creating a branch in Aegis can be accomplished with a single,
fast command.
Simple On-disk Formats
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.
Lightweight, Standard Servers
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.
Distributed Operation
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.
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.
