Messages in this thread | | | Subject | Re: The Linux Kernel Project Management System (INITIAL PROPOSAL) | Date | Tue, 28 Sep 1999 09:41:11 +0000 | From | Peter Miller <> |
| |
Larry McVoy writes: > On Mon, Sep 27, 1999 at 04:32:13PM -0400, Jordan Mendelson wrote: > > distributing source among several repositories. The alternative > > solution is written by Peter Miller and is known as Aegis. > > Aegis supports all the features required for large project > > development including distributed repositories, change sets, > > and simultaneous active branches.
I posted a proposal about this a few months ago. (Fri 26 Mar 1999 "Proposal: Aegis to manage Linux kernel development") It went into some detail, folks may wish to read the article from the archives, and refresh their memories (that way this reply is kept smaller).
Please note that Aegis models the change lifecycle, it isn't just a file babysitter. It sets out to do a LOT more than simple file versioning.
> Cool. So explain to us how Aegis handles the following: > > . disconnected operation with updates to all repositories
You have a local copy, of course (just like folks do now, just like any other tool requires). Except, instead of hammering on it directly, you work in a change set.
> . undo - including things you don't do but incorporated
I'm assuming here that Larry is refering to change sets, or parts thereof, which arrived from a "foreign" source and have subsequently been incorporated into the repository. A rather artificial distinction from change sets produced by other local staff.
Aegis doesn't have uncomditional commit/incorporate. However, if you did decide to incorporate a "foreign" change set, or any other change set for that matter, and later wish to remove it, you create another change set, add the historical versions of the relevant file (i.e. before the unwanted change) and proceed as normal. Pretty boring stuff, really, same as all systems do.
Note: Aegis *doesn't* magically whisk the change set out of the sequence, and reproject the repository. Repository transactions, like any database transaction, are NOT COMMUTATIVE in the general case. Aegis requires that all changes be validated, including undoing.
> . multiple views, each of which include some subset of the others
Each branch is "overlayed" on its parent branches. Files which are not modified by a branch are inherited from the parent branch, so if the parent branch changes, these changes "propagate" into the child. Various "insulation" schemes are possible on top of this basic mechanism.
For multiple views, use multiple branches - without insulation.
> . compressed repositories
The history tool is decoupled from Aegis. You can use whatever you wish. You can put a compressing wrapper shell script around RCS or SCCS if that is what you need. Aegis doesn't care, just so long as it can get the info back out again.
There is an option, but it defaults to off, to compress Aegis' database files. This is transparent. It typically is much smaller than the history files, so the savings are much smaller, in comparison.
With the cost of disk plummeting faster than developers can crank out code, the extra CPU overhead rarely seems worth it. But if you want to, you can.
> . disk and/or file systems which corrupt the underlying files
This is Larry's hobby horse. Aegis leaves operating system reponsibilities with the operating system. If your file system corrupts files, it has a BUG. Fix the OS, not all of the apps which -> depend <- on it. Sheesh.
> . low bandwidth links
Aegis decouples the transmition of the change set. You can use just about anything: email, ftp, web, sneaker not, just tell Aegis the command you want executed. BUT: that means Aegis doesn't know or care about the bandwidth of your link. It does, by default, gzip|mpack the change set, but you can turn either or both off (e.g. no mpack when I'm distributing using FTP.)
Also, if you want to use PGP, add it to the command you tell Aegis for how to send change sets.
Aegis supports a huge variety of distribution topologies: it provides a change set, you distribute it however you want. Aegis supports whatever granularity you want: you can distribute individual change sets, aggregated change sets (there is a hierarchy, pick the level), or the whole shebang; you choose.
Two *really* big deals:
1. The reception mechanism includes trojan detection. Well: detection of potential trojan vectors: things like the change set modifies the Makefile (you build you get infected) or shell sripts (you run you get infected) or test scripts (you test you get infected). This list of vector filename patterns is per-project configurable.
If a potentian trojan file is present in a change set, Aegis stops the incorporation of the change set earlier than usual, to be checked by a human before it builds or tests (usually, Aegis automatically builds it and tests it, and leaves is waiting for a human reviewer).
(You can also turn it off trojan check in your procmail filter script, if, say, it come from Linus and has a valid PGP signature.)
2. No UNCONDITIONAL commits. Ever. The whole commit portion of other tools is broken into pieces, with validation prerequisites. Aegis' goal is to keep the repository working (see the Aegis User Guide for more on this, it's long). That means *no* validation exceptions - not even when stuff arrives from Linus Himself. No way any incoming patch from IDontKnowYou is going into my repository without any preconditions! (Really simple preconditions like "the repository still builds" and "the repository still tests out OK")
3. Aegis is open source. Bitmover is ajar source.
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |