Aegis 4.24

Here is a quick list of the key features of Aegis:

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.


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.

The beautiful graphics on this web site are by Grégory Delattre.

Return to the Aegis home page.