GEOS Git Transition

This page will detail the transition of GEOS from CVS to Git.

Assignments

git_transition_assignments

Pre-transition activities

Note that some aspects of the transition may be useful artifacts to preserve. The read-only archive of the CVS repo at the very least, but possibly other aspects as well.

Hosting service

Decide on which hosting service to use. Available options are GitHub, NASA internal GitHub (restricted to US citizens), BitBucket, GitLab etc. Also, who will manage this service (NCCS, GMAO,...)

This should be part of the policy document. Though that document probably just needs to state that there will be an officially designated hosting service.

Create policy document

This is mostly on Tom/Arlindo, but are hoping for contributions from Jing and Purnendu.

Create/assemble training materials

Generic/introductory Git

• https://stackoverflow.com/questions/802573/difference-between-git-and-cvs
• https://git-scm.com/docs/gittutorial
• https://confluence.atlassian.com/bitbucketserver/basic-git-commands-776639767.html

Git for CVS users

• https://www.lsc-group.phys.uwm.edu/daswg/docs/howto/git4cvs.html
• https://gist.github.com/btilford/716213/f504ee44c5849bd0107193beb96eec2684f6e9a4
• http://genomewiki.ucsc.edu/index.php/Git:_CVS_equivalent_operations

Discussions with stake-holders in GMAO

The SMT has requested that we come up with a transition plan and bring it back to them. This activity is being led by Arlindo and Tom, and has begun with high-level presentations to the major stakeholders. So far we have covered:

• Ricardo Todling
• Jing Guo
• Purnendu Chakraborty
• Larry Takacs
• Yury Vikhliaev
• Justin Perket
• Andrea Molod
• Mike Manyin

On tap are:

• ?

Accepted without discussion:

• Bill Putman

Obtain official list of historical tags/modules

Nominally this is from Ricardo

Git_tags_from_CVS

Create superDAS CVS module

The thought here is to find a home for existing CVS module work that is not captured by DAS tags. For each DAS tag, there will be an analogous superDAS tag that only differs for files/directories that are not part of DAS.

The SuperDAS module has been created. It should encompass the LDAS, GESOctm, QFED, AGCM, DAS, and the coupled Ocean. The QFED/LDAS/CTM directories are now living under the src directory along side GEOSgcs.

Need to verify that the "modules" will build under superDAS module checkout while still in CVS

• How to hide other directories?
• What changes are needed in Makefile?
• Can we make the changes work robustly with the "real" modules in the mean time?
• Verify build
  1. GEOSctm
  2. LDAS
  3. GEOSagcm
  4. GEOSadas
  5. coupled Ocean
• Verify run
  1. GEOSctm
  2. LDAS
  3. GEOSagcm
  4. GEOSadas
  5. coupled Ocean

Testing plan

How do we verify that the Git repository has the necessary information. Ideally in some automated fashion.

Day (:-1)

Probably need to split this day into specific early goals. Here I have lumped all work that must precede the transition with an attempt to at least be cronological.

• Develop geos-git script. This script will clone GEOS and use sparse tree to present a narrow "module" view of the code.
  • Features:
    1. module name (optional - default to superDAS?)
    2. repository URL (optional - default to main repo)
    3. branch (optional - default to master)
    4. tag (optional - no default)
• Create "public" repo
  • Nominally NASA's public git hub
  1. Verify open source status. How?
  2. Contact NASA GitHub administrators - create repo
     • Request control of branches and hooks
     • Update NASA Github directory service
  3. Request NASA GitHub access via NAMS for core developers
     • Tom Clune
     • Matt Thompson
     • (GCM dev branch) Larry Takacs
     • (DAS dev branch) Ricardo Todling
     • (Ops) Rob Lucchesi
  4. Get regular GitHub accounts for all GEOS developers
     • Send out instructions to GMAO all.
• During the lead up to the trigger date, we need to send out frequent reminders to GMAO-all to commit what they can in CVS.

Day 0 steps (in order)

1. Freeze CVS - use ACL CVS
   1. Need to ensure that Tom and Matt have suitable permissions
   2. How do we test this?
      1. Quickly on a Monday morning and then undo?
2. Run CVS-to-Git script.
3. push to community repo
   1. Should there be some testing before push?

Then proceed to testing

Day 1 Core team testing/verification

• Verify that all designated tags have been captured.

1. % git clone
2. % foreach tag in $initial_git_tags; do git checkout $tag; done

• Verify that select CVS modules build with final tag

  % foreach module in $cvs_modules; do
  % geos-git clone -m $module -r repo -o dir-name
  % <build>
  % rm -rf $module
  % done

• Verify that operations CVS module runs and produces identical results to CVS.

Day 3 Everyone else

• Send email to developers (or GEOS all)
  • Request that they verify that they can checkout, build, and run model

Discussion/strategies/approaches

Sandbox

It will be important to try out ideas, so we need a simple (possibly slow) mechanism to automatically create a Git repo from the CVS repo. Indeed, this recipe should itself probably be tracked with version control and evolve as we determine the best action. Ideally the steps for Day 0 are then to clone this repo and execute the conversion script. Branches can be used to explore/propose alternate approaches.

In the same vein it might be useful to be able to "clone" the existing CVS repo so that experiments (e.g., creating the "super" DAS CVS module) can be tried and consequences explored. I think that Atanas and I both have permissions to make a deep copy of the repository and put it somewhere accessible on Discover.

Atanas has created a sandbox. (Need details.)