Aegis Features

.\" .\" aegis - project change supervisor .\" Copyright (C) 2004-2006, 2008 Peter Miller .\" .\" 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 3 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, see .\" . .\" .de an-p-footer .. .ad l .hy 0 .so version.so
.br .br .br

#
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 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. .\"
- .\" 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.
- 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. .br

# Features

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

## Meaningful Configuration Names

.br 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. .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 .so footer2.so