FCM 1.3 Release Notes
30 January 2008

These are the release notes for FCM release 1.3. You can use this release of FCM freely under the terms of the FCM LICENSE, which you should receive with this distribution.

Note that FCM now requires Subversion 1.4.0 or later (previous releases only required Subversion 1.2.0).

FCM is maintained by the FCM team at the Met Office. Please feedback any bug reports or feature requests to us by e-mail.


What's New?

Build and extract:


Code management commands:


Minor enhancements & Bug Fixes


Code management commands:



Known Issues

The following are known issues with this release of FCM which we plan to address in later releases:

System Requirements


The core part of FCM is a set of Perl scripts and modules. For the build system to work, you need the following modules installed:

The code management commands and extract system need the following additional modules installed:

To use the simple GUI for some of the code management commands, you also need the following modules:

At the Met Office we are currently using the complete FCM system with Perl 5.8.x. In addition the build system is being used with Perl 5.6.x.


To use the code management commands (and relevant parts of the extract system) you need to have Subversion installed.

Note that the extract system can mirror extracted code to a remote platform for building. Therefore it is only necessary to have Subversion installed on the platform where you do your code development. If you use other platforms purely for building and running then you do not need to have Subversion installed on these platforms.


The use of Trac is entirely optional (although highly recommended if you are using Subversion).

Other Requirements

The fcm conflicts command requires xxdiff. At the Met Office we are currently using version 3.1. The fcm diff --graphical command also uses xxdiff by default although other graphical diff tools can also be used.

The extract system can use diff3, which is part of GNU diffutils, to merge together changes where the same file is modified by two different branches (compared with the base branch). At the Met Office we are currently using version 2.8.1.

The build system requires GNU make. At the Met Office we are currently using version 3.79.x and 3.80.

Optionally, the build system can use f90aib to generate interface files. However, there is also a built in Perl based interface file generator which is quicker and better in most cases so you are unlikely to need f90aib unless you hit a problem with some particular code.

FCM is intended to run on a Unix/Linux system. It is currently used at the Met Office on Linux (Red Hat Enterprise 2.1 and 4.5) and HP-UX 11.00.


FCM is distributed in the form of a compressed tar file. Un-pack the tar file into an appropriate location on your system. Then add the bin/ directory into your PATH. Once you have done this you should now have full access to the FCM system, assuming that you have met the requirements described in the previous section.

If you wish to define keywords for your systems you will need to create a file etc/fcm.cfg. An example file, fcm.cfg.eg, is provided which is a copy of the file currently used at the Met Office. For further details please refer to the section FCM keywords in the System Admin chapter of the User Guide.

The doc/ directory contains all the system documentation.

The tutorial/ directory contains the files necessary to set up a tutorial repository. This will allow you to follow the tutorial section in the User Guide.

The templates/ directory contains various example scripts which you may find useful. Note that these scripts are all specific to the Met Office and may contain hard coded paths and email addresses. They are provided in the hope that you may find them useful as templates for setting up similar scripts of your own. However, they should only be used after careful review to adapt them to your environment. The contents are as follows:

This script restricts write-access to the repository by checking the following:
A simple post-commit hook script which runs the script post-commit-background in the background.
This script runs in the background after each commit This script is installed as standard in all our repositories.
An example of how you may want to set up a background_updates.pl script to perform post-commit tasks for a specific repository. This script uses a lock file to prevent multiple commits in quick succession from causing problems.
A simple pre-revprop-change hook script which runs the script pre-revprop-change.pl.
If a user attempts to modify the log message of a changeset and he/she is not the original author of the changeset, this script will e-mail the original author. You can also set up a watch facility to monitor changes of log messages that affect particular paths in the repository. For further details please refer to the section Watching changes in log messages in the System Admin chapter of the User Guide.
A simple post-revprop-change hook script which runs the script post-revprop-change.py.
This hook script updates the Trac SQLite database following a successful change in the log message.
An example of how you might set up a cron job to make use of the <repos>.latest file.
The cron job which we run each night. It verifies and backs up each of our repositories, housekeeps the revision dumps created by post-commit-background and backs up each of our Trac systems. It also handles the distribution of FCM to various platforms at the Met Office.
This script sets up a new Trac system and applies some configuration options which we use by default at the Met Office.
This script allows us to recover all of our Subversion repositories by using the nightly backups and the repository dumps.