CASA Code Management

Overview

The CASA group for NRAO/ALMA/EVLA (not NRAO GB) has switched from CVS to subversion for code management. Information about subversion may be found at http://subversion.tigris.org. With the switch to subversion, we chose not to import the glish based code and much of the documentation. The old glish based AIPS++ may still be accessed via CVS.

The code repository resides on https://svn.cv.nrao.edu/svn/casa/casa.v2. Within the code repository we have branches/active , beta/VERSION (where VERSION is a release tag like v2.0.3803) and trunk. NRAO(Not GB)/ALMA/EVLA develop on branches/active. Outside developers may request a development branch. Such requests need to be sent to Darrell along with who needs access. The trunk will always be either the most current stable or be what will become the next stable. It is always guaranteed to build provided the developer has all the build tools installed.

Please visit CASAInstallFromSource for more details on installing CASA. To commit changes back to the svn repository you will need an svn username and password which you can get from Darrell.

Mechanics

Since we now do not base our releases on a snapshot of the active branch, the developer marks the submitted code as "Ready for release". A template for code check in maybe found in code/xmlcasa/install/svntemplate. Two shell scripts setsvneditor.sh and setsvneditor.csh allow you to set the SVNEDITOR environment variable, which pops up the editor with the templated already loaded.

1. Simply mark Ready for Release as Yes in the template.
   1. new code must include unit tests

The integrator regularly checks the svn commit logs for ready to release code. For code marked ready to release he

1. checks out trunk
2. merges changes from the active branch to the candidate trunk
3. runs unit tests
4. runs regressions tests
5. commits changes if all tests are OK otherwise reports error and abandons this merge.

Conflicts

If svn cannot determine how to reconcile your version with the repository version, it will prompt you with options including:

• e (edit): sounds good, looks good, but silently inserts a checkin log template at the top of each edited file. This is not what you want.
• l (launch): Would launch a tool to help you fix things, if you have defined what to use. setsvneditor.(c)sh does not do that for you.
• tf (accept theirs, fully): Sounds bad, but it's really good.
  1. cp your version outside the code tree
  2. tf
  3. You now have the 2 versions on your local disk, and can reconcile them at your leisure. (ediff in emacs does the job very well.)

-- WesYoung - 13 Nov 2006