GEOS-5 Software Engineering: Difference between revisions
| Line 47: | Line 47: | ||
===== Approaches, loopholes etc. ===== | ===== Approaches, loopholes etc. ===== | ||
There are two basic approaches to perform configuration management under CVS: | |||
# Two separate bracnches | |||
#* Development branch - free for all | |||
#* Production bracnch: lead custodian merges dev->prod | |||
# 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 | |||
==== GEOS-5 Systems and Modules ==== | ==== GEOS-5 Systems and Modules ==== | ||
Revision as of 09:53, 29 March 2013
Overall Configuration Management
Source Code Configuration Management
General Policies
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:
- Two separate bracnches
- Development branch - free for all
- Production bracnch: lead custodian merges dev->prod
- 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