CASA Source Code Change Control

CASA uses Subversion for source code change control. This page describes how we use Subversion.


Version Control with Subversion is a good on-line tutorial and reference. This link is for Subversion 1.6, the version of Subversion client included on our primary development OS, RHEL 5.

All CASA developers should read at least:

Organization

CASA Subversion repositories are moving toward Subversion organization conventions:

  • A top level repository for each project containing
    • A trunk, used for feature development and bug fixing.
    • A directory containing branches, with one branch per directory: no nesting.
    • A directory containing tags, with one tag per directory: no nesting.

These conventions are described more completely in Version Control with Subversion - Chapter 4. Branching and Merging - Repository Layout.

We chose to move to these conventions to allow CASA developers to use any Subversion clients they choose and expect these clients to be to branch, merge, and tag source within our repositories as expected. Some Subversion clients fail to find branches and tags if Subversion conventions are not followed.

Repositories

CASA source code repositories are located at:

The CASA data repository is located at:

CASA 3rd party code repositories are located at:

  • https://svn.cv.nrao.edu/svn/rpmbuild - current 3rd party code repository
    • Does not follow Subversion conventions for historical reasons.
    • To be retired by CASA. It will continue to be used by other NRAO projects.

Access

With one exception (to be documented), all CASA source code, data, and 3rd party source code used by CASA is readable by anyone who can reach our Subversion servers.

Write access is restricted to authorized CASA developers.

Branches

Test

The test branch, located at https://svn.cv.nrao.edu/svn/casa/branches/test, includes code to be packaged in casapy-test packages. This branch is to be deleted in favor of building casapy-test packages from tags set on the trunk. This change is on hold pending process changes to be documented.

At this time, the test branch is used in the following process

  1. Daily, the change log for the trunk is checked for commits that have not been merged to the test branch.
    1. Checked out copies of trunk are evaluated on EL5, EL6, OS X 10.7, and OS X 10.8.
      1. Checked out copies are updated,
      2. built (usually incrementally),
      3. tested running the full functional test suite, a subset of the regression test suite, and the irc10216 CASA Guides based test.
      4. If there is an increase in failing tests,
        • the process stops here and developers are notified,
        • else, the process proceeds.
    2. Changes not marked "not ready for test" are merged from the trunk to branches/test/
      • Conflicts may occur. Resolution may require assistance from the developer who committed the change on trunk.
    3. New changes on branches/test/ are built, and tested as described for trunk
      1. If results are consistent with the trunk,
        • proceed,
        • else, search for merge errors.
  2. Weekly (typically Thursday), build casapy-test package on EL5, OS X 10.7.
  3. Weekly (typically Friday), casapy-test package EL5, EL6, OS X 10.7, and OS X 10.8.
    1. If results are consistent with the trunk,
      • publish,
      • else, search for packaging errors.

Stable

The stable branches, located at https://svn.cv.nrao.edu/svn/casa/branches/stable-YYYY-MM, includes code to be packaged in casapy-stable packages. In the future, we will build casapy-stable packages from tags set on the trunk. This change is on hold pending process changes to be documented. Existing branches/stable-YYYY-MM will remain until we set a policy on deleting old branches.

At this time, stable branches are used in the following process

  1. Monthly (before the 15th), check the current state of the branches/test and ensure it is good enough to publish a casapy-stable package. * If so, copy branches/test to branches/stable-YYYY-MM, where YYYY is the current year and MM is the current month and proceed, * else, work with developers to resolve issues until test is good enough.
  2. The new branches/stable-YYYY-MM code is built and tested as described for trunk
    1. If results are consistent with the test branch,
      • proceed,
      • else, search for branching errors.
  3. Build casapy-stable package on EL5, OS X 10.7.
  4. Test casapy-stable package EL5, EL6, OS X 10.7, and OS X 10.8.
    1. If results are consistent with the trunk,
      • publish,
      • else, search for packaging errors.

Project

The project branches, located at https://svn.cv.nrao.edu/svn/casa/branches/project-NAME, include code being worked on by one or more CASA developers that is being isolated from trunk development.

  • Any developer or group of developers may create a project branch at any time.
  • Developers are responsible for cleaning up their project branches after they have merged there work back to trunk.

To create a project branch

  1. Chose a descriptive, short project name that explains the purpose of the project.
    • For example: Extend Multithreading
  2. Convert the project name into a directory name.
    • For example: project-extend-multithreading
      • Use all lower case words.
      • Separate words with "-" characters.
      • If the name includes period characters (for example, for version numbers), replace these with "_" characters.
        • It is common to checkout code using the branch name in the directory name. Some CASA 3rd party packages (flex?) fail when run on data in directories with names containing "."
  3. Use Subversion to copy code from the source to the new branch.
    • Typically, you will want to branch from the head of the trunk. To do so

svn cp https://svn.cv.nrao.edu/svn/casa/trunk https://svn.cv.nrao.edu/svn/casa/branches/project-NAME

For atypical cases, see Scott Rankin.

Tags

Section to be written

-- ScottRankin - 2013-09-10
Topic revision: r5 - 2014-01-23, ScottRankin
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback