Aegis (fwd)

A discussion I thought the folks here would find interesting. As the spec
consolidates, let's at least take a brief look at Aegis.

        Brian

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
collab.net  |  open source  |  do what's right  |  now hiring smart people 
---------- Forwarded message ----------
Date: Tue, 25 Apr 2000 09:54:36 +0000
From: Peter Miller <millerp@canb.auug.org.au>
To: dcms-dev@eros-os.org
Subject: Aegis
I suspect that John hasn't used Aegis very much, or he may have given
a slightly different summary.  From the discussion so far, I think Aegis
is actually a far better fit than folks may suspect.
I'll preface the following by saying that I'm aware this list is
about <i>the</i> DCMS, and the following is about Aegis, a dcms.
I'm not out to start a flame war, just to provide more accurate info.
(Comare and contrast: "control" and "take over".)
Jonathan S. Shapiro (shap@eros-os.org) writes:
> CVS: I've been using this since 1991, and I'm not happy with it. It
> doesn't really do configurations at all,
Aegis has this.
> and it lacks a notion of a local
> repository, which is vital for people who work over slow links or
> portables.
Aegis has this.
> I could live with all of this if it got directories and rename
> right, but it doesn't.
Aegis can handle rename.  Not necesarily well, but better than CVS, which
isn't saying much.  It could do better - it has the metadata, it doesn't
yet have the code.  (Hint!)
> If it were for some reason necessary for me to
> recover the version of EROS as it existed in 1992 I don't think I could do
> it, and if a CM system doesn't give you that, it doesn't give you anything
> at all.
Aegis has this - but you'd have to hav the verion there, first.
> PRCS: no remoting, no rename handling, not complete soon enough. I think
> that Josh McDonald is doing a whole bunch of interesting things with PRCS,
> and I suspect that the stuff *I* am doing is largely complementary. He has
> focused primarily on back-end and comm issues, while I'm taking the view
> that disk is cheap and I need configurations.
Aegis likewise: cofigurations first, compression second.
Also, Aegis is here now.
> AEGIS: Seems to be
Try it, first, please.
> total overkill. Aegis wants to take over your entire
> lifecycle model, and I don't want that.
Software folks have been telling themselves
their projects are so unique for so long, they believe their own press.
(But we keep using the same tools (gcc, make, cvs) on all the projects:
tell me again about unique?)  Hell, we manage to look at our code design
issues analytically and find commonality and modularity; take a moment
to look at development process analytically.  We all write code, we all
(say we) test code, we all (say we) review code, we all (say we) want
a secure repository.  And then Aegis comes along, and does all that you
say you want, and suddenly it's overkill?  (OK, so you pushed my button.)
> Aegis wants to take over [...] and I don't want that.
Only in the sense that cruise control takes over your car.
As for not wanting it, you *do* want controls (see below).  Without
first installing the ability to at least veto (if not more), you
can't have *any* management control.  Superficially, that may look
like "taking over" but given that Aegis can <i>and is</i> used by
single developers, as well has large sites, the controls can be
configured across a huge range.  You can turn the cruise control
off without ripping it out.
> I spent years building CASE tools,
> and there simply doesn't exist a single, universally applicable lifecycle
> management model. For starters, I just want configuration management, but
> see below.
Agreed there is no universal lifecycle model.  Aegis only does
*configuration* modeling - and a lowest common denominator, at that.
It does model the development lifecycle of a change set, however release
lifecycles tend to be bigger and uglier, and not what Aegis adddesses
(directly).  Plus, you can build on Aegis' development process for more
complex systems, or more complex authentication states and stages.
The flip side is that ``management'' word you used.  That you want to
`manage' something inevitably means you want to control it - otherwise
you are just a spectator.  Aegis actively manages, in the sense that it
gives you the controls to do the managing with (so, yes, Aegis does
take over the whole change set lifecycle - otherwise management of it
is not possible).
> Open source imposes some requirements for access.
Aegis be configured for a wide range of access levels and methods,
from open source to corporate paranoid, and all the spots in between.
> Security certification
> imposes some requirements for access *control*.
Aegis gives you that control, plus audit trails.
> We need
> a means to have branches that are tightly controlled by the core
> developers,
Aegis has this.
> and simultaneously a means for any Tom, Jane, or Harry to make
> changes in a local version for later submission into the pot.
Aegis has this.
> Further, we
> need a means for corporations to build *private* branches that are not
> externally visible until a release occurs (if ever).
Aegis has this.
> Finally, we need a
> system that can let two companies set up a shared workspace with some
> reasonable story for security.
Aegis has this.  (Including secure private repository replication and/or
updates over the Internet.)
> [dcms does] need lifecycle integration [eventually]
Which is why it's always been there in Aegis.
It's exceptionally hard to retrofit - or CVS would have it, no?
> Replicated repository -- it should be possible to obtain consistent
> checkouts (though not always the most recent) from any repository
> replicate.
Aegis has this.
> Replication should be controllable on a project by project basis.
Aegis has this.
> Subordinate repository -- it should be possible to clone a project
> (or the recent history of one) to my workstation/portable, work there
> disconnected with all management features available, and then re-sync
> the changes back to a master repository.
Aegis has this.
 
> Configurations, not files -- the CM system should consider a "commit" to
> be a complete new image of the project (though many files will probably
> be unchanged) as opposed to a set of changes/additions/deletions to
> individual files.
Aegis has this.
> Programmability -- it should be possible to embed trigger scripts in a
> project. These scripts should run successfully on all platforms.
Aegis has this.
> One NON-requirement: build control. This is a fine thing to pursue,
> but I'ld like to start by getting configurations of blobs right first.
Aegis has this.
Build mgnt helps answer the question `is this configuration actually atomic?'
("Helps". Necessary but not complete, as the theoreticians would say.)
> The CM system should have per-branch access control. That is, it should
> be possible to have an "official" branch that is world readable but
> modifiable only by select people. Simultaneously, Jack Random should
> be able to take a given readable branch and create a new working branch
> accessable only to Jack Random or his designates.
Aegis has this.
> I'm partial to cryptographic solutions here, as they provide the most
> reliable means of identity that I know about
Aegis has this - configure it to use PGP or GPG or whatever.
> The "change set" commits atomically or not at all.
Aegis has this.
In summary, I think you crossed Aegis off your list too soon.
But then I would, wouldn't I?  So, test my assertions...
	http://www.auug.org.au/~millerp/aegis/
Also: Aegis is open source, and it's available now.
Regards
Peter Miller	E-Mail:	millerp@canb.auug.org.au
/\/\*		WWW:	http://www.canb.auug.org.au/~millerp/
Disclaimer: The opinions expressed here are personal and do not necessarily
	reflect the opinion of my employer or the opinions of my colleagues.