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/