.\"
.\" aegis - project change supervisor
.\" Copyright (C) 1999, 2001, 2002, 2004-2008, 2010, 2012 Peter Miller
.\"
.\" This program is free software; you can redistribute it and/or modify
.\" it under the terms of the GNU General Public License as published by
.\" the Free Software Foundation; either version 3 of the License, or
.\" (at your option) any later version.
.\"
.\" This program is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
.\" General Public License for more details.
.\"
.\" You should have received a copy of the GNU General Public License
.\" along with this program. If not, see .
.\"
.nh 1 "CVS Comparison"
.PP
This chapter presents a brief comparison of Aegis and CVS.
.nh 2 "Never Trust A Skinny Chef"
.PP
This is a comparison of Aegis and CVS, but it's written by an Aegis
expert who isn't a CVS expert. This means that, from time to time,
information may be biased in Aegis' favour even though I'm trying to
be even handed. Worse, there are probably inaccuracies stemming from
my lack of familiarity with CVS: if you find any, I'd certainly like to
know, so I can correct this document.
.nh 2 "Contributors"
.PP
In putting this chapter together, I solicited assistance from users
on the \f[CW]aegis\[hy]users\fP mailing list. Where you are reading
their comments and not mine, you'll see it as a name at the end of
the paragraph.
.nh 2 "The Aegis Process"
.PP
.ad r
\[lq]\fIWriting software is hard, improving the way that software is
written is harder.\fP\[rq] Bill Pugh
.ad l
.PP
Aegis sets out to perform configuration management. This is very
different to version control, but to see why you'll need to understand
what Aegis thinks a configuration is.
Also that \[lq]management\[rq] word impies a degree of authorization and
reporting, which Aegis also provides.
.IP \(bu 2n
A configuration is a snapshot of the source files, \fIall\fP source files
in the project, immediately after a commit. A single identifier can be
used to recreate all source files for any one commit, and it isn't a date.
(It's like a CVS tag, but different. It carries more information and
exists long
before the commit.)
.IP \(bu 2n
The complete audit path for every file is available from this single
identifier. It includes who and when, with change set comments, not
simply comments attached to each file which just happen to be the same.
.IP \(bu 2n
Implicit in this, is that a commit is performed for a set of files,
not one file at a time.
.IP \(bu 2n
For each commit, the files are not simply plonked into the repository.
They must also compile successfully, they must also pass tests. Just as
some database systems validate transactions before allowing a commit,
so does Aegis require validation.
.IP \(bu 2n
In order to enforce this validation, no\[hy]one on the project has write
permission to the repository. Not even the staff authorized to commit
changes.
.IP \(bu 2n
The only method of changing the repository is through Aegis, and this
is always validated, and always peer reviewed, and it always leaves a record.
.IP \(bu 2n
To support all of this, and private work areas too, Aegis imposes
a process. It is said that all software development uses a process,
but it usually isn't written down.
Aegis provides a process, but it is very flexible and can be easily
adapted for your project's needs, from single person projects to huge
team projects.
.IP \(bu 2n
Version control is an important part of this process, but
in Aegis it is like the foundations of a house: essential, but usually
unattractive and largely out of sight.
.LP
Aegis delegates as much as possible to other tools, both because they
already exist and don't need re\[hy]writing, and also to provide developers
with maximum choice. One of the easiest ways to think of Aegis, to
misquote the X11 folks, is
.ce 1
Aegis is about rules, not tools.
.br
because the rules (the process) is the \[lq]missing bit\[rq] Aegis was written
to provide.
The "management" part of software configuration management.
.nh 2 "CVS has no Built\[hy]in Process"
.LP
\[lq]By not having a process built into CVS, the team must work out a process
separately. Since you're not likely to do better than the Aegis process,
the likely result is to do worse. Also you will have to expend effort
to implement and enforce the process.\[rq]
\fITrenton G. Twining \fP
.LP
\[lq]Every project I've seen \fIuse\fP either Aegis or an Aegis approach,
so drastically outshines other projects in the same organization, it's
clear to me that the Aegis approach is the difference. It works better
with some analysis. It works better with some planning and forethought.
It works.\[rq]
\fITrenton G. Twining \fP
.LP
\[lq]For one thing, [Aegis] was actually designed, rather than just having
accreted like CVS. And if you are looking for code reviews and all
that stuff, it's probably easier to do them with Aegis (with CVS it is
a roll\[hy]your\[hy]own type affair).\[rq]
\fIJim Kingdon \fP
(for many years, the chief CVS maintainer)
.nh 2 "The Good, the Bad and the Ugly"
.LP
This section contains the answers to some frequently asked questions.
.nh 3 "Why should I change from CVS to Aegis?"
.IP \(bu 2n
enforced review \- damn important in a company environment
\fIGus \fP
.IP \(bu 2n
mandatory testing (this may be disabled, per project)
.IP \(bu 2n
More space efficient for large code trees, and only one copy of the
baseline (also makes backup easier)
\fIGus \fP
.IP \(bu 2n
To maintain control over your code repository. The baseline can't even
be written to by developers, so the audit trail is more secure.
\fIGus \fP
.IP \(bu 2n
Support for change sets.
My main complaint with CVS is that you are unable to associate
modified files into a change so once the files are committed to the CVS
repository, there is no easy way to back it out or work out which
other files were changed as part of a logical set.
\fITim Potter \fP
.IP \(bu 2n
Separation of the roles of developer, reviewer and integrator. At the
moment, typical distributed CVS development happens with people
checking in stuff as they develop it with very little integration
testing as they go along. It's pretty much up to people "in the know"
to manually go through changed files and check to see if something has
been broken by a developer. It gets even tricker when there are
particular assumptions made that aren't written down.
\fITim Potter \fP
.IP \(bu 2n
Automated testing support.
.nh 3 "What features does CVS have that Aegis hasn't?"
.IP \(bu 2n
Low change overhead.
Developers can omit as much of the process as they feel like.
.IP \(bu 2n
Partial checkins.
You can commit just a few files from your work area.
.IP \(bu 2n
Works with both Windows and Unix.
Aegis still struggles with this, and only has weak support for Windows.
.nh 3 "How do I do CVS\[hy]style remote development?"
.PP
A comprehensive answer will require quite a
bit of understanding how Aegis' development process works.
See the "Teamwork" portion of Aegis Howto and the "Geographically
Distributed Development" chapter of the Aegis User Guide for more
information. Here, however, is a brief summary.
.PP
"CVS\[hy]style remote development" is a development model whereby there is one
master "server" containing an authoritative copy of the repository, and
developers run CVS "clients" which contain shadow copies of the repository
which are locally updated by developers to add new code. Periodically each
local site must "pull" down the latest changes which others have committed
to the server (via "cvs update"), and "push" its own updates back to
the server to make them visible to others (via "cvs commit"). Merging
and conflict resolution occurs at commit time, and no one is responsible
for (or able to) ensure the integrity of the master repository, because
anyone can commit garbage at any time, thus corrupting the baseline. The
corrupted baseline then propagates to all clients.
.PP
Aegis's remote development can emulate this model, although Aegis
supports a much broader range of distributed development topologies,
as well as providing security against a corrupted baseline.
.PP
Here is one way of doing CVS\[hy]style remote development using Aegis. You
need: one server machine running Aegis, many client machines running
Aegis, and optionally but recommended a web server (this can be the
same machine as the web server, or a separate machine). Briefly, you
create an Aegis project on a designated "server" site, create a change to
populate the server repository with project files, then distribute this
change with aedist (via email, WWW, or any other transport mechanism)
to the client sites.
.PP
Each client site sets up a local Aegis project,
receives the first aedist change set from the server, which populates the
client's repository. Then each client does local development against
the local repository via changes, and submits these changes as they
are integrated back to the server via aedist change sets (email, WWW,
or any other transport mechanism).
.PP
The server receives these aedist change sets from clients,
integrates them into the server repository, and republishes them
(again via aedist) for all clients to receive (the originating client
will receive the same change set again, but aedist is smart enough to
recognize if the change already exists, so it does not get applied
a second time at the originating client site).
.PP
This differs from the CVS model because no one can directly update the
server repository via "cvs commit" analogue; clients can only submit a
change, but the server must integrate it before it is accepted by the
server and published for consumption by other clients. Similarly, the
server cannot directly update a client's repository via "cvs update";
the server can only inform the client of new changes, but the client
must integrate the changes before they are accepted into the client's
local repository. Notice that server and client operations are identical:
both publish changes, and both accept changes from external sources.
.PP
Merging and conflict resolution occur at the time of receipt of the change
(either by the server when it receives a local update from a client,
or by the client when it receives a "master update" from the server).
Aegis changes are automatically distributed as patch files and complete
source file copies, and when Aegis receives the changes, it first attempts
to use the patch file, thus doing merging automatically. Should the
merge produce a conflict with the local (and hence updated) version of
the file, the development directory for the received change will contain
the copy of the file provided in the change, which naturally cannot
reflect any changes to the file made locally. The developer is given
ample opportunity to notice this merge conflict because Aegis requires
that the received change must build, that it must pass its tests, that
the developer generate difference files to see the exact effect of the
change, that it be reviewed, and that it be properly integrated.
.PP
Note that if for any reason a client gets badly out of sync with the
server (for instance if the client loses track of which aedist change sets
it has already applied), the client can always download an aedist change set
containing the server's entire project baseline, and apply this to the
client's local repository (using the aedist \-receive \-nopatch option,
which forces the received files to be applied as\[hy]is and not to try to
patch the files). This will effectively synchronize the client's
repository with the server's baseline, at which point the client can
again download and apply incremental aedist change sets from the server.
Also note
that this situation can be avoided by keeping server and client well
synchronized; one way of doing this is via e\[hy]mail automation, whereby
the server automatically sends out aedist change sets via e\[hy]mail to all
interested clients when the server integrates such a changeset. The clients
could have a procmail filter to automatically pipe such messages through
aedist \-receive, at which point the change sets from the server are
automatically unpacked and built, thus requiring only that they be
reviewed and integrated.
.PP
Finally, notice that the server is not
"authoritative" in any technical sense. The server publishes changes which
clients are encouraged but not required to accept; the final authority
for acceptance of a change into any repository is the integrity of the
repository itself, enforced by the Aegis process.
.nh 4 "Loose command equivalents"
.LP
Here are some command which provide similar features to what CVS users
may be familiar with.
.\" From: Normaln
.\" Date: Tue, 22 Oct 2002 13:30:01 +0000
.TS
tab(;);
lw(1.8i) lw(1.8i) lw(1.8i).
_
T{
A. To access a remote server:
T};;
T{
Copy of the remote project repository to a local project repository.
T};T{
Fetch the latest complete version from
a web server running the Aegis CGI interface.
Process this downloaded \[lq].ae\[rq] file with
\fIaedist \-receive\fP,
building and integrating with the usual Aegis process.
T};T{
Analogue of first\[hy]time remote \fIcvs co\fP.
T}
T{
Receive the latest change sets from the remote server
T};T{
Fetch the latest complete version \fIor\fP
the individual change sets of interest, from
a web server runnjing the Aegis CGI interface.
Process this downloaded \[lq].ae\[rq] file with
\fIaedist \-receive\fP,
building and integrating with the usual Aegis process.
T};T{
Analogue of remote \fIcvs update\fP.
T}
T{
Send a change set to a remote server
T};T{
Use the
\fIaedist \-send\fP command, and send the to the project maintainer.
This is usually done by email.
T};T{
Analogue of remote \fIcvs commit\fP.
T}
_
T{
B. To set up a server for others to access:
T};T{
The Aegis CGI interface may be installed using the \fIaeget.instal\fP command.
You need to be running Apache.
T};T{
CVSup, \fIetc\fP
T}
T{
Receive and integrate changesets from contributors
T};T{
The project maintainer uses the \fIaedist \-receive\fP command on change
sets received via email, or \fIaepatch \-receive\fP for ordinary
patches, or \fIaetar \-receive\fP for tarballs. Automatic processing
via procmail is also possible, but authentication (\fIe.g.\fP GnuPG)
is essential.
T};T{
Much like the usual \fIpatch\fP command.
T}
.TE
.\" vim: set ts=8 sw=4 et :