Re: Aegis Jonathan S. Shapiro (shap@eros-os.org)
Wed, 26 Apr 2000 11:11:04 -0400

Peter:

> ... I'm aware this list is about *the* DCMS, and the following
> is about Aegis, a dcms. I'm not out to start a flame war, just to
> provide more accurate info....

First, and foremost, welcome!

I've been away the last week, but it was on my to-do list to encourage you to join the discussion here, because I was aware of Aegis and I think that it many respects it does indeed provide what I think I want. There are some places where I am not clear on the model, and I'ld like to ask you about them. Also, there are many things you said in your email that do not leap out at me from the documentation, and I'ld like to ask you about those as well. Finally, there are some things in your note that I can't find in the docs, and I wonder if you might provide pointers to those.

I want to emphasize once again that the purpose of the DCMS list is to arrive at a configuration management system that will work for the EROS project. Since I hate doing things one-off, I'm interested in broader application as well. If the best way to do that is to pick up Aegis, that would be wonderful. If the solution proves to be to start from Aegis and evolve, that would also be great.

Topics are in all caps.

WORKFLOW:

> > Aegis wants to take over your entire
> > lifecycle model, and I don't want that.
> [Aegis] does model the development lifecycle of a change set...

First, thanks for the correction. I overstated the case rather badly, and I apologize.

I should preface this by saying that I find chapter 2 of the Aegis guide incredibly off-putting. This could be purely a problem with me as a reader. The best way to summarize my issue is that the word "must" appears in far too many places. I mention this for two reasons: first, so that in the course of the discussion you may be able to help me see past my issues with the description, and second to identify one of the issues that (I believe) may have limited the acceptance of Aegis.

The model itself seems like a good one, but I see no reason that it needs to be hard-coded into the tool. I don't agree that this is the only valid workflow for change sets, and I have been involved in projects that (a) eventually came to use the workflow described and (b) would have failed if they were required to use it from the start. My preference would be to put a scripting facility into the tool and implement the policy in the scripting language.

The reviewer notion makes sense. This is, in essence, an "endorsement" model, which is conceptually similar to a very old idea from Xanadu. It works quite well, but it should be optional (as, apparently, it is).

I confess that I can't tell the difference between "developer" and "integrator". This may be because I have a hidden assumption, so let me describe how I see this issue and you can perhaps straighten it out.

I imagine a world in which two branches may have differing integrity requirements. As a developer, I have a work in progress. I may wish to "check in" to that branch several times. Sometimes, there are reasons to check in a state on a developer branch that doesn't compile (if only for archival or transfer purposes). In short, this is a branch with no integrity guarantees. At the same time, I envision branches with high integrity (what your document appears to call a "baseline"). Such a branch requires all of the process described in your workflow, and possibly more.

In the terms of the Aegis document, it seems to me that there isn't any difference between a developer and an integrator. Rather, it seems to me that the difference lies in the branches themselves. If so, the only distinction I can see between these roles is which branch they can modify. It appears to me that (ignoring separation of duties for a moment) this is purely an access control issue. Also, it appears to me that the preconditions for checkin depend on which kind of branch we are talking about. This is one of the things that I think DCMS should capture in a scripting facility.

So:

  1. Taken as a model, is my understanding of the differences between these roles correct? I.e. is it purely a matter of who can check in where?
  2. If correct, why is it not expressed this way in the description?
  3. If not correct, can you expand on what is missing?

ACCESS CONTROL:

> > 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 Aegis user's guide emphasizes strongly that Aegis uses the UNIX access control model, and I am unable to reconcile this with the "use PGP/GPG" idea. Perhaps the documentation is out of date, or perhaps I am missing something. I'ld appreciate it if you might expand on this.

By way of trying to articulate my assumptions...

In speaking of "cryptographic solutions", I was speaking of digital signatures, and of using these to identify users, and of building access control on top of this. We need to move to something based on public keys or some such, primarily because we cannot rely on the existence of a common administration point. Also, we cannot rely on use of UNIX.

Can you expand on how to deploy Aegis in such a way as to replace the UNIX access control mechanism with digital signatures? If that is not a matter of configuration, can you provide some sense of how difficult it would be to integrate such a thing into Aegis?

DISTRIBUTION:

The aedist mechanism appears to be designed to ship change sets from one group to another, but it appears to assume that the parties are working at arm's length. What I'm looking for is a way to mutually cross-synch the repositories. This should not involve an additional build/review cycle, because the sending repository has already done this.

Am I missing something here?

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

If so, I failed to see it. I do see the aedist mechanism (per the above), but I don't see in the user's guide a repository synchronization mechanism between mutually trusting repositories. How does this work?

In particular, what happens when I create a branch in my repository that happens to have the same name as a branch in your repository? How is the collision resolved during synchronization?

More generally, I see no description of how naming is handled in the repository. Given the possible use of RCS, it's not clear to me that Aegis controls the names at all. In the absence of universally unique names I don't see how to get a collision-free synchronization mechanism...

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

Can you expand on this? How would Tom, Jane, or Harry go about this? Also, how is the "config" file, which appears to be per-project, turned into something that is per-branch?

COMPRESSION AND DELTAS

> > He [Josh McDonald] 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.

Thanks to Josh, I've revised my opinion on this slightly. I'm not interested in solving the compression problem myself, but I want to engineer into the interface the necessary support to ensure that it can be done. At the moment, I've moved to a design in which the common operation on entities is:

revise(old-version, new-version)

A trivial repository implementation is free to ignore this information and simply store the new version, but it hopefully provides enough information to get a place to stand to figure out what to compute the delta from.

REMOTING

The Aegis code does not appear to make a client/server split between the repository management code and the user agent. The recommended usage for Windows is via Samba.

Have I failed to understand something?
If not, for what reason did you avoid a client/server design?

SCRIPTING

> > Programmability -- it should be possible to embed trigger scripts in a
> > project. These scripts should run successfully on all platforms.
>
> Aegis has this.

I can't find this in the user's guide. Can you provide a pointer to a section?

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

Can you provide a pointer into the user's guide or the reference manual?

Thanks -- and welcome once again.

Jonathan