.\" .\" aegis - project change supervisor .\" Copyright (C) 1991, 1992, 1993, 1999, 2000 Peter Miller; .\" All rights reserved. .\" .\" 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 2 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, write to the Free Software .\" Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, USA. .\" .\" MANIFEST: User Guide, The Change Development Cycle, The Reviewer .\" .bp .nh 2 "The Reviewer" .LP The role of a reviewer is to check another user's work. You are helped in this by Aegis, because changes can never reach the .I "being reviewed" state without several preconditions: .LP \(bu The change is known to build. You know that it compiled successfully, so there is no need to search for syntax errors. .LP \(bu The change has tests, and those tests have been run, and have passed. .LP This information allows you to concentrate on implementation issues, completeness issues, and local standards issues. .LP To help the reviewer, a set of "command D" files is available in the change development directory. Every file which is to be added to the baseline, removed from the baseline, or changed in some way, has a corresponding "comma D" file. .nh 3 "Before You Start" .LP Have you configured your account to use Aegis? See the \fIUser Setup\fP section of the \fITips and Traps\fP chapter for how to do this. .nh 3 "The First Change" .LP Robyn finds out what changes are available for review by asking Aegis: .E( robyn% \f(CBaerpass -l -p example.1.0\fP Project "example.1.0" List of Changes Change State Description ------- ------- ------------- 10 being_reviewed Place under Aegis robyn% .E) Any of the above changes could be reviewed, Robyn chooses the first. .E( robyn% \f(CBaecd -p example.1.0 -c 10\fP aegis: project "example": change 1: /u/pat/example.1.0.C010 robyn% \f(CBaedmore\fP \fI\&.\&.\&.examines each file.\&.\&.\fP robyn% .E) The .I aedmore command walks the development directory tree to find all of the "comma D" files, and displays them using \fImore\fP(1). There is a corresponding .I aedless for those who prefer the \fIless\fP(1) command. .LP Once the change has been reviewed and found acceptable, it is passed: .E( robyn% \f(CBaerpass -p example.1.0 10\fP aegis: sh /usr/local/lib/aegis/rp.sh example.1.0 10 pat robyn aegis: project "example.1.0": change 10: passed review robyn% .E) Some time soon Isa will notice the email notification and commence integration of the change. .nh 3 "The Second Change" .LP Most reviews have the same pattern as the first. .E( robyn% \f(CBaerpass -l -p example.1.0\fP Project "example.1.0" List of Changes Change State Description ------- ------- ------------- 11 being_reviewed file names on command line robyn% .E) .LP Always change directory to the change's development directory, otherwise you will not be able to review the files. .E( robyn% \f(CBaecd -p example.1.0 -c 11\fP aegis: project "example.1.0": change 11: /u/jan/example.1.0.C011 robyn% .E) .LP Another useful way of finding out about a change is the "list change details" command, viz: .E( robyn% \f(CBael cd -p example.1.0 -c 11\fP Project "example.1.0", Change 11 Change Details .E) .E( NAME Project "example.1.0", Change 11. .E) .E( SUMMARY file names on command line .E) .E( DESCRIPTION Optional input and output files may be specified on the command line. .E) .E( CAUSE This change was caused by internal_bug. .E) .E( STATE This change is in 'being_integrated' state. .E) .E( FILES Type Action Edit File Name ------- ------- ------- ----------- source modify 1.1 main.c test create test/00/t0002a.sh .E) .E( HISTORY What When Who Comment ------ ------ ----- --------- new_change Fri Dec 11 alex 14:55:06 1992 develop_begin Mon Dec 14 jan 09:07:08 1992 develop_end Mon Dec 14 jan 11:43:23 1992 robyn% .E) .LP Once Robyn knows what the change is meant to be doing, the files are then examined: .E( robyn% \f(CBaedmore\fP \fI\&.\&.\&.examines each file.\&.\&.\fP robyn% .E) .LP Once the change is found to be acceptable, it is passed: .E( robyn% \f(CBaerpass -p example.1.0 11\fP aegis: sh /usr/local/lib/aegis/rp.sh example.1.0 11 jan robyn aegis: project "example.1.0": change 11: passed review robyn% .E) .LP Some time soon Isa will notice the email notification and commence integration of the change. .LP The reviews of the third and fourth changes will not be given here, because they are almost identical to the other changes. If you want to know how to fail a review, see the \fIaerfail\fP(1) manual entry. .nh 3 "Reviewer Command Summary" .LP Only a few of the Aegis commands available to reviewers have been used in this example. The following table (very tersely) describes the Aegis commands most useful to reviewers. .sp .TS center,tab(;); l l. Command;Description _ aecd;Change Directory aerpass;Review Pass aerpu;Review Pass Undo aerfail;Review Fail ael;List Stuff .TE .LP You will want to read the manual entries for all of these commands. Note that all Aegis commands have a .I \-Help option, which will give a result very similar to the corresponding .I man (1) output. Most Aegis commands also have a .I \-List option, which usually lists interesting context sensitive information.