Organization of the ACCESS UM svn repository

This page is now outdated and is only relevant for models versions before vn10.0 and the move to MOSRS.

The trunk of our repository is kept in sync with the Met Office repository, applying the patches that come with each external release. After this patch an exported copy of our repository should be identical to the exported UM code in the release.

Trunk revision numbers corresponding to model versions are stored in the svn property fcm:revision (svn propget fcm:revision https://access-svn.nci.org.au/svn/um). FCM can use these directly (e.g. fcm co fcm:[email protected]).

Met Office parallel suites generally include a configuration patch for each model (possibly in different model versions). These are installed on branches from the trunk, e.g. source:/branches/dev/Share/VN7.9_PS27_Global_Configuration, source:/branches/dev/Share/VN7.8_PS27_NAE_Configuration, source:/branches/dev/Share/VN7.8_PS27_UKV_Configuration)

Some external releases include an extra set of Met Office patches to fix problems found since the version was frozen internally (described in Appendix F of UMDP X4 "Guidelines for Building the Unified Model" that also comes with each release).

Prior to vn8.0, I've created a branch from the trunk called VNm.n_local_changes, e.g. [1619]). This has included the Met Office fixes ([2705]), local configuration changes (compiler options, library paths, scripts, e.g. [1648], [1660]), simple local fixes (e.g. trivial problems that upset the Intel compiler, e.g. [1687]) and sometimes more substantial bug fixes, either locally developed or from the Met Office (e.g. fixes to surface radiation diagnostics, [3024]).

Mixing all these things together in a single branch has several drawbacks. It's not clear what has to be carried forward to a new version of the model and there can be problems merging the local configuration changes with Met Office parallel suites.

Requirements

• The trunk is kept strictly in sync with the Met Office
• Branches with Met Office parallel suite configuration patches (and climate model configuration patches) are as supplied by Met Office with no further local changes. If local changes are required for some reason they should be on a separate branch.

Recommended structure

With each UM release we will create the following branches from the trunk, (here using vn8.0 as an example)

• branches/dev/vn8.0/metoffice_patches
• branches/dev/vn8.0/access_config
• branches/dev/vn8.0/access_patches
• branches/dev/vn8.0/PSxy_Global_Configuration (as required)
• branches/dev/vn8.9/PSxy_UKV_Configuration

Note that the directory structure here has changed, /dev/vn8.0/metoffice_patches rather than /dev/Share/vn8.0_metoffice_patches. This was because /dev/Share was becoming quite cluttered. A complication here is that the FCM gui won't create a branch like this so it will have to be done from the command line.

The intended use of these branches is metoffice_patches:: Fixes that come with the external release access_config:: Configuration for solar and vayu, scripts etc. No model code changes access_patches:: Code fixes that we are sure everyone using this version needs. Only bug fixes, not optional enhancements (don't do anything like [1664] again!)

Ideally none of these will conflict with changes in the PS branches and a local build job for a parallel suite will include all these branches as well as the PS configuration branch. If not merging to create a configuration branch will be required.