Talk:Aegis (management software)

Is Aegis a revision control system at all? It seems to be rather more of a change-control system. Its purpose seems to be: to protect the official source tree from non-functioning changes, by enforcing a workflow model. Actual revision control is delegated eg: to RCS.

Yes Aegis technically delegates all the real work to three main standalone (and theoretically interchangeable [see below]) tools for build, test and file history. In Aegis jargon the Dependency Management Tool (make, cook, scons, ant, etc.) is responsible for moving from source to executable (i.e. it is what aegis -build [aeb]) calls), the test is any runnable shell script [Peter Miller {Primary developer of Aegis} has never explained why shell scripts only to my personal satisifaction], the history tool is what most people think of when they think of version control vs. your correct statement that it is a change management system (which is how Peter describes it officially).

A few notes:

• While in theory any DMT will work with aegis all the classic ones (the make family) will find it very hard to work with "split" source trees (i.e. the tree can be spread over several baselines and the development/intergration [for those not familure with Aegis's "model" checkins are a 3 step process of developer checkin, code review and intergrating into the baseline [repository in traditional version control jargon]) unless there is file system support for transparently gluing it all together in one virtual dir (like union fs does). I am not sure if Ant has the same issue or not but cook was written specifically to work with aegis [Aegis was written to manage cook orginally] and the Xcon family uses Aegis almost exclusively for it's internal development (I have never used cons/scons/etc. but I assume since the development team does all there changes via Aegis then it must be able to handle split source trees).

• "Traditional" TDD and Aegis style tests sometimes do not play well togehter... Aegis assumes that each change has a standalone test and once the change is committed that you never rewrite that test unless there is some bug or design reason that it will never pass.... namely the TDD method of having a test "class" for every real "class" and adding to the unit tests in the test class everytime new functionality is added to the class will lead to either many false failures in regression testing and/or false postives if running an older chnages set shell wrapper on the test class but the test class it self is not updated (namely aent/aet ignores everything except the shell wrapper)

BTW despite the two above "flaws" [only the second effects me... since I use cook as my DMT] I use Aegis on every possible project I can and general it is a little top heavy in the early days of a project but a life saver later on. --Aryeh M. Friedman (talk) 13:21, 28 August 2008 (UTC)