Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Source code management

A set of AIPS++ accounts and groups have been defined to perform the following functions:

• aips2mgr (uid=31415, gid=31415): Owns the AIPS++ directories, and all RCS and ftp distribution files. aips2mgr, and those in the aips2mgr group, are RCS and ftp administrators for AIPS++. In particular, they can directly invoke the rcs command on the AIPS++ RCS files. aips2mgr will have an active login account only on selected machines. aips2mgr is responsible for maintaining the ftp directories, and in particular, runs the daily exhale and inhale cron jobs.

• aips2prg (uid=31416, gid=31416): A generic programmer account, although in practice this may not often be used. The aips2prg group lists those who have permission to check code into AIPS++, or check it out with a write lock (anyone can check code out without a write lock).

• aips2usr (uid=31417, gid=31417): The aips2usr account itself could serve as a generic AIPS++ usage account if this is so desired. The aips2usr group could be used to control access to AIPS++ executables and AIPS++ data areas if this degree of control is desired by the AIPS++ administrator (the alternative being to give world execute and/or write permission).

Remote consortium sites with access to the internet can choose to NFS mount the master AIPS++ RCS directories on their local development machines. This is most conveniently done via the /net automounter map. All that is required is for the fully qualified hostname to be entered in the aips2-consortium netgroup which has been created at Charlottesville for the purpose. A symbolic link is created at the remote site as

   ~aips++/master -> /net/baboon.cv.nrao.edu/aips2/aips++/master

This gives a view into the master RCS repositories in addition to the local copy in

   ~aips++/slave

which is updated once a day. All AIPS++ makefiles access the RCS repositories via a symbolic link

   ~aips++/rcs

which is set to point to one or the other. At remote sites it normally points to slave and in Charlottesville it always points to master.

When a library or executable is rebuilt, the local rcs directories are normally the ones consulted. However, it is possible to reset the rcs ``switch'' to master at a remote site to cause make to checkout and/or rebuild AIPS++ from the master repositories. This has been tried at ATNF Epping with encouraging results.

AIPS++ programmers create their own ``shadow'' representation of the AIPS++ code directory tree by using the mktree utility which also creates symbolic links into the ãips++/master directories. They then appear to have their own private workspace with a window directly into the master RCS repositories at Charlottesville. Whenever they check code out of, or into the system from their private work area they will be dealing directly with the RCS repositories in Charlottesville.

Source code checkin and checkout is mediated by ai and ao. ai activates its alter-ego, ai_master, which resides in the ãips++/master directory itself, and runs setuid to 31415 - aips2mgr's uid in Charlottesville. This mechanism allows programmers at remote sites to check code into Charlottesville, which will certainly have a different set of uids and gids to those at their own site. The remote consortium sites will, however, be encouraged to adopt the uids and gids defined at Charlottesville for AIPS++. These were deliberately chosen to be large random numbers to minimize the likelihood of conflict with the remote site's set of uids and gids.

Whenever code is checked in to the master, ai updates the local slave copy (if present - and it won't be at Charlottesville), and also the plain text copy in ãips++/code. Since the slave repositories are owned by the local aips2mgr, ai itself runs setuid to its uid (hopefully also 31415).

ai's counterpart, ao, has a similar alter-ego called ao_master which operates in precisely the same way as ai_master, thereby allowing code to be checked out of the master with a lock on it (which requires write permission on the RCS version file).

A third useful utility, au runs setuid to the local aips2mgr account and updates slave (if present) and code with the named files from the master.