Aegis

Aegis is a transaction-based software configuration management system.

Aegis project provides a framework within which a team of developers may work on many changes to a program independently, and Aegis coordinates integrating these changes back into the master source of the program, with as little disruption as possible.

Features:

• 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 revision, not stored redundantly as in CVS.
• 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, 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

What is new in this release:

• The branch fstate can contain fake transparent entries when a change not yet integrated modifies for the first time in the branch a file. It is possible that such entries cause troubles if the project is configured to write the pfstate file. To avoid such troubles the fake transparent entries are stripped on the fly when reading the pfstate file. The way the the pfstate file is written is not modified.
• The Italian translation of error messages is now available.
• The Vietnamese and Dutch error messages has been updated.
• The aerevml(1) command was incorrectly printing twice user defined attributes. This behavior has been fixed.
• The aeclean(1) command was incorrectly checking the patterns against the absolute name of the files. This behavior has been fixed.
• The aelock(1) man page was incorrectly reporting the attribute name aelock use. This has been fixed.
• The aesub(5) man page now reference aeuconf(5) in the email address section.
• The aedist(1) command is now more robust when handling renamed files.
• The t0228a-matt.sh test script has been made more robust with respect to different behavior of libmagic.
• The t0127a.sh test script (aeimport vs. sccs) has been fixed.
• A number of memory related bugs has been fixed.
• Some typo has been corrected in the ae-repo-ci(1) man page.
• The build process has been improved to give more informative messages when a new aegis developer populate his repository for the first time.