GEOS-5 Software Engineering

Source Code Configuration Management

The ESMA Project

The ESMA project is concerned with the deployment of modeling and data assimilation applications that are part of the ESMF testbed applications.

This project is hosted at: cvsacl.nccs.nasa.gov

Project admins are:

• da Silva, Arlindo
• Lucchesi, Rob
• Todling, Ricardo
• Takacs, Larry

The ESMA CVS repository

CVSACL is a version control server intended to specifically support the access control patches to CVS (https://progress.nccs.nasa.gov/trac/admin/wiki/CVSACL). Access to CVSACL requires an NCCS account (https://www.nccs.nasa.gov/). The web interface to CVS ESMA project is available at https://cvsacl.nccs.nasa.gov/cgi-bin/.

The ESMA CVS repository has a flat directory structure designed to accommodate a variety of modeling systems. The repository holds 'Applications', 'Components' and other software libraries needed to build earth modeling systems. The directories under esma/src/ are Applications/, Components/, Config/, Couplers/, Documentation/, Shared/ and of course CVS/.

PACKAGES: A collection of source files having one or more software deliverables

• Libraries
• Executables (binaries, scripts)
• Includes (.h, .mod)
• Configuration (Resource) files (.rc)
• Examples

MODULES: CVS modules are then used to compose individual modeling systems. A module is a collection of packages comprising some stand alone application, e.g. GEOSGCM_m0 (GMAO Unified Model, GEOS-5). A complete list of ESMA CVS modules is available at CVSROOT/modules.

Some examples are:

# ESMF/MAPL Tutorial
G5tutorial        -d G5tutorial/src  esma/src/Applications/G5tutorial &Config \
                                     &GEOSgcm_Shared_m2

# Ganymed
Ganymed           -d GEOSagcm &GEOSGCM_m3

etc.

CVS/CVSACL

Approaches, loopholes etc.

There are two basic approaches to perform configuration management under CVS:

1. Two separate bracnches
   • Development branch - free for all
   • Production bracnch: lead custodian merges dev->prod
2. Single branch approach (GMAO approach)
   • Individual developers commit mods to 'development' branch
   • Custodian (gate keeper) issues tags identifying fully tested and stable releases. Checked in modifications may be accepted or rejected by the custodian
   • Branches are created only when conflicts are unavoidable

With standard CVS there is no good way to enforce either policy, and several security loopholes are present:

• Anyone with 'checkout' privileges also have 'check in' privileges. One way around is to use a Pserver which has its own vulnerabilities.
• No good way to protect tags
• User can logon to machine where repository resides and tinker with files There really is no good way to enforce CVS policies

Solution: CVS/ACL

CVS/ACL is a patch to CVS for access control list management. It provides advanced ACL definitions per modules, directories and files on branch/tag for remote cvs repository connections. As a result the execution of all CVS subcommands can be controlled with eight different permissions.

1. (n) no acess
2. (r) read - allows subcommands: annotate, checkout, diff, export, log, rannotate, rdiff, rlog, status
3. (w) write - only cvs commit/checkin action. Not allowed add/remove files to/from repository.
4. (t) tag
5. (c) create
6. (d) delete
7. (a) full access except admin rights
8. (p) acl admin

The advantages of CVS/ACL are:

• Branches/packages are protected from modification from 'non-authorized' groups.
• General users check out code, experiment with it and check in modified files to their 'own private branches'.
• Tags from major releases are protected from modification by non-authorized users.
• General users are not allowed to directly manipulate repository files.

CVSACL implementation

1. CVSROOT :ext:USERNAME@cvsacldirect:/cvsroot/esma
2. Development is conducted on the trunk (a.k.a HEAD)
   1. Packages on this branch are associated with one or more GMAO development groups.
   2. The custodian groups have 'full access' (a) to the packages on this branch, all other have 'read' and 'tag' (rt) privileges.
   3. General users modifying files (for which they do NOT have check-in privileges) commit these files on their own private branches.

For uniformity, we suggest following the CVS Best Practices.