**************** Ideas from Aegis **************** * Very mature -- in use for 14 years, many large projects, etc. * "Essential process can be learned in a day" -- which is still kind of a long time; i'd like it to be well under an hour. * Good process integration; show who is supposed to be working on what and how far through they are. * Very poor Windows support. * Distributed repositories. (??) * Very focussed on security -- can reproduce any previous revision; availability/integrity/confidentiality; uses Unix permissions and seteuid() to prevent users changing the database. * Does not itself track history -- assumes this will be done by some other tool such as RCS operating on the baseline. * I think every individual project needs a single baseline. (??) * The baseline is always working and always releasable -- to the extent that you have scripts which can enforce this. * Integration step is somewhat similar to that used by distributed systems. It seems that you could build some features of aegis as policy macros on top of Bazaar-NG. * The baseline also contains object files built from current source, which can be used to pre-populate working directories. Also people only need a copy of the source files they're changing. I think the economics of this have changed a bit. Also tends to assume all developers are on the same Unix host, which is no longer generally true. * Only one review/integration can be in process at a time. * One process difference is that developers produce all changes; reviewers/integrators can only accept or reject them. This is different from the integrator-makes-right model of many distributed tools. (Though the integrator still has the choice to reject, but they have the option of fixing it too.) * Can automatically append Signed-off-by field. Interesting idea. I wonder if we should have a metadata facility to include licence data? * Much of the functionality of Aegis is to prevent people doing things they could otherwise do. That can be useful in enforcing a healthy process but bazaar-ng is not the place for it. * Can serialize an (in-progress) changeset to text, and then mail from one place to another. * Branches are an extension of the 'change' concept; they can be merged into the parent in the same way that a change can be. Merging branches onto the mainline seems to hit a similar problem to that of centralized branches. If someone else has committed, you need to make a new changeset reconciling all their changes, commit that to the child branch, then commit everything to the parent. This suggests a different way to do shared branches in Bazaar-NG: You can push to the parent if you incorporate either directly or by merger all changes on the parent. That means that everything someone has committed to the parent is present in some way in your branch. By extension, it is safe to transform the parent text into your branch without losing anything. We can therefore remotely record that changeset to the parent. This is more or less what Aegis does. The problem with this in the Bazaar-NG model is that then the new commit will be only in the parent, and not on the child. So if you run ``bzr log`` on the child, you won't see what you just committed. We can't apply it to both because the predecessor is different. (darcs could do that, but it has a looser patch history than I want.) Overall, the process model is good for a particular type of organization. It would be good to build this on top of Bazaar-NG. To support that we need: - patches are submitted, rather than being directly written in - arbitrary levels of branching/review - users can submit changes to branches they are not directly allowed to write to - branches can be cleanly removed when they're no longer necessary - strong audit trail Interestingly, the BitKeeper model which is criticized__ by Greg Hudson is similar to that of Aegis: a single integrator (or small team?) who ultimately decide what gets into the main tree. __ http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot The Aegis workflow can probably be `emulated in bzr `_.