





.













                           Aegis

                A Project Change Supervisor




                    CVS Transition Guide







                        Peter Miller

                  _m_i_l_l_e_r_p_@_c_a_n_b_._a_u_u_g_._o_r_g_._a_u































CVS Transition Guide                                   Aegis


.
























This document describes Aegis version 4.24
and was prepared 23 October 2008.






This  document  describing  the Aegis program, and the Aegis
program itself, are
Copyright (C) 1991, 1992,  1993,  1994,  1995,  1996,  1997,
1998,  1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008 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 ver-
sion.

This program is distributed in the hope that it will be use-
ful, but WITHOUT ANY WARRANTY; without even the implied war-
ranty of MERCHANTABILITY or FITNESS FOR  A  PARTICULAR  PUR-
POSE.   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
<http://www.gnu.org/licenses/>.




Page 2        (./lib/en/cvs-comparison/main.ms) Peter Miller





Aegis                                   CVS Transition Guide


11..  CCVVSS CCoommppaarriissoonn

     This chapter presents a brief comparison of  Aegis  and
CVS.

11..11..  NNeevveerr TTrruusstt AA SSkkiinnnnyy CChheeff

     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.

11..22..  CCoonnttrriibbuuttoorrss

     In  putting  this  chapter together, I solicited assis-
tance from users on the aegis-users mailing list.  Where you
are  reading their comments and not mine, you'll see it as a
name at the end of the paragraph.

11..33..  TThhee AAeeggiiss PPrroocceessss

     "_W_r_i_t_i_n_g _s_o_f_t_w_a_r_e _i_s _h_a_r_d_, _i_m_p_r_o_v_i_n_g _t_h_e _w_a_y _t_h_a_t _s_o_f_t_-
_w_a_r_e _i_s _w_r_i_t_t_e_n _i_s _h_a_r_d_e_r_."  Bill Pugh

     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 "management" word impies a degree of autho-
rization and reporting, which Aegis also provides.

+o A configuration is a snapshot of the source files, _a_l_l
  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.)

+o 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.

+o Implicit in this, is that a commit is performed for a set
  of files, not one file at a time.

+o 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 vali-
  date transactions before allowing a commit, so does Aegis
  require validation.




Peter Miller    (lib/en/cvs-comparison/c1.so)         Page 3





CVS Transition Guide                                   Aegis


+o In order to enforce this validation, no-one on the project
  has write permission to the repository.  Not even the
  staff authorized to commit changes.

+o 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.

+o To support all of this, and private work areas too, Aegis
  imposes a process.  It is said that all software develop-
  ment 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.

+o 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.

Aegis delegates as much as possible to other tools, both
because they already exist and don't need re-writing, and
also to provide developers with maximum choice.  One of the
easiest ways to think of Aegis, to misquote the X11 folks,
is
              Aegis is about rules, not tools.
because the rules (the process) is the "missing bit" Aegis
was written to provide.  The "management" part of software
configuration management.

11..44..  CCVVSS hhaass nnoo BBuuiilltt--iinn PPrroocceessss

"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."  _T_r_e_n_t_o_n _G_. _T_w_i_n_i_n_g _<_t_g_t_@_c_y_c_l_e_-
_t_i_m_e_._c_o_m_>

"Every project I've seen _u_s_e 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."
_T_r_e_n_t_o_n _G_. _T_w_i_n_i_n_g _<_t_g_t_@_c_y_c_l_e_t_i_m_e_._c_o_m_>

"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-your-own type
affair)."  _J_i_m _K_i_n_g_d_o_n _<_k_i_n_g_d_o_n_@_p_a_n_i_x_7_._p_a_n_i_x_._c_o_m_> (for many
years, the chief CVS maintainer)






Page 4          (lib/en/cvs-comparison/c1.so)   Peter Miller





Aegis                                   CVS Transition Guide


11..55..  TThhee GGoooodd,, tthhee BBaadd aanndd tthhee UUggllyy

This section contains the answers to some frequently asked
questions.

11..55..11..  WWhhyy sshhoouulldd II cchhaannggee ffrroomm CCVVSS ttoo AAeeggiiss??

+o enforced review - damn important in a company environment
  _G_u_s _<_g_u_s_@_g_e_t_s_y_s_t_e_m_s_._c_o_m_>

+o mandatory testing (this may be disabled, per project)

+o More space efficient for large code trees, and only one
  copy of the baseline (also makes backup easier) _G_u_s
  _<_g_u_s_@_g_e_t_s_y_s_t_e_m_s_._c_o_m_>

+o To maintain control over your code repository.  The base-
  line can't even be written to by developers, so the audit
  trail is more secure.  _G_u_s _<_g_u_s_@_g_e_t_s_y_s_t_e_m_s_._c_o_m_>

+o 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 reposi-
  tory, there is no easy way to back it out or work out
  which other files were changed as part of a logical set.
  _T_i_m _P_o_t_t_e_r _<_T_i_m_._P_o_t_t_e_r_@_a_n_u_._e_d_u_._a_u_>

+o Separation of the roles of developer, reviewer and inte-
  grator.  At the moment, typical distributed CVS develop-
  ment 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.  _T_i_m _P_o_t_t_e_r _<_T_i_m_._P_o_t_t_e_r_@_a_n_u_._e_d_u_._a_u_>

+o Automated testing support.

11..55..22..  WWhhaatt ffeeaattuurreess ddooeess CCVVSS hhaavvee tthhaatt AAeeggiiss hhaassnn''tt??

+o Low change overhead.  Developers can omit as much of the
  process as they feel like.

+o Partial checkins.  You can commit just a few files from
  your work area.

+o Works with both Windows and Unix.  Aegis still struggles
  with this, and only has weak support for Windows.

11..55..33..  HHooww ddoo II ddoo CCVVSS--ssttyyllee rreemmoottee ddeevveellooppmmeenntt??

     A comprehensive answer will require quite a bit of
understanding how Aegis' development process works.  See the



Peter Miller    (lib/en/cvs-comparison/c1.so)         Page 5





CVS Transition Guide                                   Aegis


"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.

     "CVS-style remote development" is a development model
whereby there is one master "server" containing an authori-
tative 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.

     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.

     Here is one way of doing CVS-style remote development
using Aegis.  You need: one server machine running Aegis,
many client machines running Aegis, and optionally but rec-
ommended 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.

     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).

     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).

     This differs from the CVS model because no one can
directly update the server repository via "cvs commit" ana-
logue; clients can only submit a change, but the server must
integrate it before it is accepted by the server and



Page 6          (lib/en/cvs-comparison/c1.so)   Peter Miller





Aegis                                   CVS Transition Guide


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.

     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 develop-
ment 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.

     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-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 down-
load 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-mail automation, whereby the server
automatically sends out aedist change sets via e-mail to all
interested clients when the server integrates such a change-
set.  The clients could have a procmail filter to automati-
cally 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.

     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



Peter Miller    (lib/en/cvs-comparison/c1.so)         Page 7





CVS Transition Guide                                   Aegis


Aegis process.

11..55..33..11..  LLoooossee ccoommmmaanndd eeqquuiivvaalleennttss

Here are some command which provide similar features to what
CVS users may be familiar with.

-------------------------------------------------------------
A. To access a
remote server:
Copy of the remote   Fetch the latest     Analogue of first-
project repository   complete version     time remote _c_v_s
to a local project   from a web server    _c_o.
repository.          running the Aegis
                     CGI interface.
                     Process this down-
                     loaded ".ae" file
                     with _a_e_d_i_s_t
                     _-_-_r_e_c_e_i_v_e, build-
                     ing and integrat-
                     ing with the usual
                     Aegis process.
Receive the latest   Fetch the latest     Analogue of remote
change sets from     complete version     _c_v_s _u_p_d_a_t_e.
the remote server    _o_r the individual
                     change sets of
                     interest, from a
                     web server run-
                     njing the Aegis
                     CGI interface.
                     Process this down-
                     loaded ".ae" file
                     with _a_e_d_i_s_t
                     _-_-_r_e_c_e_i_v_e, build-
                     ing and integrat-
                     ing with the usual
                     Aegis process.
Send a change set    Use the _a_e_d_i_s_t       Analogue of remote
to a remote server   _-_-_s_e_n_d command,      _c_v_s _c_o_m_m_i_t.
                     and send the to
                     the project main-
                     tainer.  This is
                     usually done by
                     email.
-------------------------------------------------------------
B. To set up a       The Aegis CGI        CVSup, _e_t_c
server for others    interface may be
to access:           installed using
                     the _a_e_g_e_t_._i_n_s_t_a_l
                     command.  You need
                     to be running
                     Apache.





Page 8          (lib/en/cvs-comparison/c1.so)   Peter Miller





Aegis                                   CVS Transition Guide


Receive and inte-    The project main-    Much like the
grate changesets     tainer uses the      usual _p_a_t_c_h com-
from contributors    _a_e_d_i_s_t _-_-_r_e_c_e_i_v_e     mand.
                     command on change
                     sets received via
                     email, or _a_e_p_a_t_c_h
                     _-_-_r_e_c_e_i_v_e for
                     ordinary patches,
                     or _a_e_t_a_r _-_-_r_e_c_e_i_v_e
                     for tarballs.
                     Automatic process-
                     ing via procmail
                     is also possible,
                     but authentication
                     (_e_._g_. GnuPG) is
                     essential.









































Peter Miller    (lib/en/cvs-comparison/c2.so)         Page 9





CVS Transition Guide                                   Aegis


22..  AAeeggiiss CCoommmmaannddss ffoorr uunnrreeccoonnssttrruucctteedd CCVVSS uusseerrss

This section compares Aegis commands and CVS commands.
There can be no exact correspondence, because they are each
actually attempting to achieve something different.

-------------------------------------------------------------
Create a new         aenpr                cvs init
project.  (In both
cases, you then
have to add con-
tent.)
-------------------------------------------------------------
Create a new work    aenc;aedb            mkdir
area.                _o_r tkaenc
-------------------------------------------------------------
Copy files into a    aecp                 cvs checkout
work area
-------------------------------------------------------------
Add a new file       aenf _f_i_l_e_n_a_m_e        cvs add _f_i_l_e_n_a_m_e
-------------------------------------------------------------
Add a whole direc-   aenf .               cvs import
tory tree as new
files.
-------------------------------------------------------------
Remove a file        aerm _f_i_l_e_n_a_m_e        cvs remove _f_i_l_e_-
                                          _n_a_m_e
-------------------------------------------------------------
Build in a work      aeb                  make
area.
-------------------------------------------------------------
Bring a work area    aem                  cvs update
up-to-date with      _(_h_o_w_e_v_e_r_, _m_e_r_g_i_n_g
the repository.      _(_t_h_e _"_m_" _i_n _a_e_m_)
                     _i_s _r_e_q_u_i_r_e_d _m_u_c_h
                     _l_e_s_s _o_f_t_e_n_)
-------------------------------------------------------------
Finish development   aede                 cvs commit
of a change.         _(_a_n_d _t_h_e_n _i_t _n_e_e_d_s
                     _t_o _b_e _r_e_v_i_e_w_e_d _a_n_d
                     _i_n_t_e_g_r_a_t_e_d_)
-------------------------------------------------------------
Rename a source      aemv _o_l_d_-_n_a_m_e _n_e_w_-   mv; cvs remove;
file                 _n_a_m_e                 cvs add
-------------------------------------------------------------
Show the differ-     aediff               cvs diff
ences between the
work area and the
repository.
-------------------------------------------------------------







Page 10         (lib/en/cvs-comparison/c2.so)   Peter Miller





Aegis                                   CVS Transition Guide


Partial commits      aeclone              cvs commit _f_i_l_e_-
are forbidden in     _T_h_i_s _c_l_o_n_e_s _t_h_e      _n_a_m_e
Aegis.  However,     _w_h_o_l_e _c_o_m_p_l_e_t_e
it is possible to    _c_h_a_n_g_e_.  _N_o_w _u_s_e
do something very    aecpu _e_t_c_, _i_n _t_h_e
similar.             _c_l_o_n_e_d _c_h_a_n_g_e _t_o
                     _g_e_t _r_i_d _o_f _t_h_e
                     _f_i_l_e_s _y_o_u _d_o_n_'_t
                     _w_a_n_t _t_o _c_o_m_m_i_t
                     _y_e_t_.
-------------------------------------------------------------
How do I browse      aecd -bl             mkdir _s_o_m_e_w_h_e_r_e
the sources?         _n_o_w _l_o_o_k _a_r_o_u_n_d      cd _s_o_m_e_w_h_e_r_e
Please note that                          cvs checkout
Aegis has a copy                          _n_o_w _l_o_o_k _a_r_o_u_n_d
sitting there
already.  With CVS
you have to create
one first.
-------------------------------------------------------------
How do I find        aefind | grep        find | grep
stuff in source
files?
-------------------------------------------------------------
Clean out every-     aeclean              make clean
thing but primary
source files from
a work area.
-------------------------------------------------------------
Make a separate      aecp -independent    cvs export
copy of sources in
the repository.
-------------------------------------------------------------


22..11..  HHooww ddoo II uussee aa RReemmoottee SSeerrvveerr??

There is no direct equivalent, but see the section in this
document titled "How do I do CVS-style remote development?"
for an explanation of how to simulate this development model
using Aegis distributed development tools.  For more infor-
mation on Aegis' distributed development model and tools,
see _a_e_d_i_s_t(1) or the "Teamwork" section of the HOWTO, or the
"Geographically Distributed Development" chapter of the User
Guide.

22..22..  HHooww ddoo II ssyynncchhrroonniizzee aann AAeeggiiss pprroojjeecctt wwiitthh aa CCVVSS
pprroojjeecctt??

This situation might occur if you are using Aegis to track
your source code changes to a project which is primarily
managed in CVS.  For this discussion we assume you have a
CVS work directory in which you checked out the latest CVS
sources.  Further we assume that these source files have



Peter Miller    (lib/en/cvs-comparison/c2.so)        Page 11





CVS Transition Guide                                   Aegis


been imported and integrated into an Aegis project.  Then,
some time passes, and you have updated your Aegis sources
via changes, and the CVS tree has also been updated via com-
mits.  The question is how can to synchronize the two source
trees.  The answer is to use patch files.

To import the latest CVS changes, create a copy of the CVS
tree.  Assume the old CVS tree is called cvs/ and the new
copy is called new_cvs/.  In the new_cvs/ directory, run
"cvs update" to get the newest sources.  Then run "diff -Nur
cvs/ new_cvs/ -x Entries.Log > patchfile" to generate a
patchfile showing the differences between the old and new
CVS trees.  Use _a_e_p_a_t_c_h to import this patchfile into an
Aegis change, then follow the usual Aegis change procedure
(build, test, diff, review, integrate).  (The _a_e_t_a_r(1) com-
mand is another possibility.)

To export your changes into CVS, again use _a_e_p_a_t_c_h to export
your Aegis changes as patchfiles.  Apply this patch to your
local CVS tree (you might want to make a copy first), then
execute "cvs commit" to submit your changes.  Or, if you
don't have write access to the CVS repository, send the
patchfile via other means (_e_._g_. e-mail) to the project CVS
maintainers.

































Page 12         (lib/en/cvs-comparison/c3.so)   Peter Miller





Aegis                                   CVS Transition Guide


33..  IImmppoorrttiinngg aanndd EExxppoorrttiinngg

It is possible to import a CVS repository into Aegis, while
preserving all of your history information.

Because Aegis uses change sets and CVS does not, it is nec-
essary for Aegis to "synthesize" the change sets during the
import process.  See the _a_e_i_m_p_o_r_t(1) command page for a com-
plete description of how this is done.  Once the change sets
have been discovered, the _a_e_i_m_p_o_r_t(1) command then synthe-
sizes an Aegis change for each one, and enters it into the
Aegis database as if it had taken place using Aegis.

Once this has occurred, you may then access all of the pre-
vious versions of the files as you would for any other Aegis
project.  See _a_e_c_p(1) for more information, particularly the
--ddeellttaa option.  All of the various lists and reports are
also available (see _a_e_l(1) and _a_e_r(1) for more information).
The usual web browsing is also available.

33..11..  IImmppoorrttiinngg ffrroomm CCVVSS

The command which does the importing is simple enough, but
there is some setup required first.

+o It is usual to have a separate account which "owns" an
  Aegis project.  This means that accidental file writes
  while browsing sources can't happen, among other reasons.
  Whether you have a separate account per project, or a
  hold-all source account doesn't bother Aegis (the more
  security conscious among you, however, will want one
  account per project).  If you have one account per
  project, name it after the project (there's less to remem-
  ber that way).  This example will call the both the
  account and the Aegis project "example".

+o It is also possible to have a separate Unix group for each
  project.  This means that you can have fine-grained con-
  trol over who has read access to your repository.  (Or, as
  above, you may want a simple source group.)  Note that
  write access to the repository is controlled via a differ-
  ent mechanism in Aegis; the repository itself will be
  read-only to _a_l_l staff, including authorized developers
  and integrators.  (See the User Guide for how your changes
  actually reach the repository.)  If you decide to have a
  group per project, use the same name as the project as,
  again, there is less to remember.

+o Login as the example user.

+o You need to decide where your Aegis project is going to
  live.  It could live below the example user's home direc-
  tory, but it does not have to.  (It is impractical for it
  to actually _b_e the example user's home directory.)



Peter Miller    (lib/en/cvs-comparison/c3.so)        Page 13





CVS Transition Guide                                   Aegis


  Wherever you put the project directory, it must be acces-
  sible from all workstations and/or servers upon which
  development _a_n_d code reviews are to be carried out.  (See
  the "Teamwork" chapter of the HOWTO for more information.)
  In this example, we are going to put it in /projects/exam-
  ple; again, named for the project.

+o If you have a single project under your $CVSROOT directory
  tree, you use the commands

       unset AEGIS_PATH
       aeimport $CVSROOT -project example -dir /projects/example -verbose

  Depending on how big your project is, this may take some
  time.  You will be informed of progress, though it will
  not mean very much if you are new to Aegis.

+o If you have several modules under your $CVSROOT directory
  tree, and the module you wish to import is contained under
  a single directory, use a command such as this:

       unset AEGIS_PATH
       aeimport $CVSROOT/example -project example -dir /projects/example -verbose

  Again this may take some time.

+o If you have a more complex module structure below $CVS-
  ROOT, it may be necessary to duplicate and manually rear-
  range the directories until you have a single directory
  tree you can point the _a_e_i_m_p_o_r_t(1) command at.  There is
  no support for reading the $CVSROOT/CVSROOT/modules file
  at this time.

+o If something goes wrong part way through (_e_._g_. running out
  of disk space) you will be left with a partial Aegis
  project that isn't very useful.  Use the

       aermpr example

  command to get rid of it.

+o Once the _a_e_i_m_p_o_r_t(1) command completes successfully, you
  need to use the command

       ae_p example.1.0
       ael project_files

  to examine the names of the files Aegis has imported.  If
  they don't match your expectations (_e_._g_. if the directory
  tree is not the shape you need) remove the project
  (_a_e_r_m_p_r) and re-run _a_e_i_m_p_o_r_t(1) with the appropriate argu-
  ments.





Page 14         (lib/en/cvs-comparison/c3.so)   Peter Miller





Aegis                                   CVS Transition Guide


+o The above commands create a project called "example", with
  branches "1" and "1.0" (see the Branching chapter of the
  User Guide for how branching works in Aegis).  To access
  branch 1.0, you use the project name "example.1.0".  If
  you wanted no branches at all (just a trunk) then add
  "-version -" to the above _i_m_p_o_r_t(1) commands.  If you are
  new to Aegis, and don't understand what this paragraph is
  talking about, _d_o _n_o_t change anything.

+o The last thing you do as the example user is to add your
  normal account as a project administrator.

       aena _y_o_u_r_l_o_g_i_n

  Now logoff the example account, and login to your normal
  account.

+o Aegis has populated the development roles with staff found
  during the import.  Use the _p_r_o_j_e_c_t _s_t_a_f_f report to exam-
  ine and verify the resulting settings.

       ae_p example.1.0
       aer projstaff

  If there are staff in inappropriate roles, use the follow-
  ing commands to rearrange them.

                               Add       Remove
             Developer       _a_e_n_d(1)    _a_e_r_d(1)
             Reviewer        _a_e_n_r_v(1)   _a_e_r_r_v(1)
             Integrator      _a_e_n_i(1)    _a_e_r_i(1)
             Administrator   _a_e_n_a(1)    _a_e_r_a(1)

  See the User Guide for more information about the various
  roles within Aegis.

+o You need to customize the aegis.conf file for your
  project.  In order to do this, you will need to create a
  change set to modify the file.  The worked example in the
  User guide will be useful in understanding how this is
  done.  It is essential that you use a change set for this;
  editing the baseline directly is a _b_i_g no-no.  See also
  the configuration examples directory,
  /usr/local/share/aegis/config.example, for some pre-built
  configuration settings.  (It's probably a Bad Idea to mess
  with the history command settings, but the rest are fair
  game.)
  In  particular, your need to set the build command.  The
  _a_e_i_m_p_o_r_t(1) command has set it to "exit 0".  See the
  Dependency Maintenance Tool of the User Guide for more
  information.

You project should now be ready to use.  Happy developing!




Peter Miller    (lib/en/cvs-comparison/c3.so)        Page 15





CVS Transition Guide                                   Aegis


If you have questions, it is worth subscribing to the aegis-
users mailing list.  See
http://www.canb.auuf.org.au/~millerp/aegis/ for how to do
this.

33..22..  EExxppoorrttiinngg ttoo CCVVSS

If it becomes necessary to export your project from Aegis
into CVS, this may be done relatively simply.

+o This method only works if you have been using RCS as your
  history tool.

+o Backup your CVS repository.  The next step will change it.

+o Copy the ,v files from the Aegis history tree into the CVS
  root tree (the Aegis project in this example is called
  "example".

       ae_p example.1.0
       aecd -bl ../history
       tar cf - . | ( cd $CVSROOT ; tar xf - )

  Note that this assumes that the two directory trees are
  the same shape.  It is highly likely that you have a mod-
  ule called something like "example", which would change
  the last line above to look like

       tar cf - . | ( cd $CVSROOT/example ; tar xf - )

  More baroque directory structures will require more manual
  mangling during the copy.

Note that Aegis' expectations of locking, access lists, key-
word expansion, _e_t_c, are rather different to CVS, so it may
be necessary to use _f_i_n_d(1) and _r_c_s(1) to set things the way
you want.




















Page 16       (./lib/en/cvs-comparison/main.ms) Peter Miller





Aegis                                   CVS Transition Guide


.
























































Peter Miller  (./lib/en/cvs-comparison/main.ms)      Page 17





CVS Transition Guide                                   Aegis


.
























































Page xviii    (./lib/en/cvs-comparison/main.ms) Peter Miller





Aegis                                   CVS Transition Guide



                     TTaabbllee ooff CCoonntteennttss


1. CVS Comparison . . . . . . . . . . . . . . . . . . . . . .   3
1.1. Never Trust A Skinny Chef  . . . . . . . . . . . . . . .   3
1.2. Contributors . . . . . . . . . . . . . . . . . . . . . .   3
1.3. The Aegis Process  . . . . . . . . . . . . . . . . . . .   3
1.4. CVS has no Built-in Process  . . . . . . . . . . . . . .   4
1.5. The Good, the Bad and the Ugly . . . . . . . . . . . . .   5
1.5.1. Why should I change from CVS to Aegis?   . . . . . . .   5
1.5.2. What features does CVS have that Aegis hasn't?   . . .   5
1.5.3. How do I do CVS-style remote development?  . . . . . .   5
1.5.3.1. Loose command equivalents  . . . . . . . . . . . . .   8
2. Aegis Commands for unreconstructed CVS users . . . . . . .  10
2.1. How do I use a Remote Server?  . . . . . . . . . . . . .  11
2.2. How do I synchronize an Aegis project with a CVS
project?   . . . . . . . . . . . . . . . . . . . . . . .  11
3. Importing and Exporting  . . . . . . . . . . . . . . . . .  13
3.1. Importing from CVS . . . . . . . . . . . . . . . . . . .  13
3.2. Exporting to CVS . . . . . . . . . . . . . . . . . . . .  16




































Peter Miller  (./lib/en/cvs-comparison/main.ms)      Page mi





CVS Transition Guide                                   Aegis



























































Page mii                     ()                 Peter Miller


