# FCM 1.1 Release Notes 06 November 2006

These are the release notes for FCM release 1.1. You can use this release of FCM freely under the terms of the FCM LICENSE, which you should receive with the distribution of this release. Release 1.1 is the first external release of FCM. (Release 1.0, 30 November 2005, was an internal Met Office release which marked the start of the main migration of systems into FCM.)

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 system:

- Support building of Fortran `BLOCKDATA` program units.
- Option to generate Fortran interface files in lower case names after their program units.
- Allow renaming of main program targets using the build configuration file.
- The `fcm_env.ksh` file now provides an environment variable for the `etc/` sub-directory of the build which can be used if you are building data files.
- The build root directory is now locked while a build is running. This prevents multiple instances of build running in the same directory. However, you can bypass the lock if you specify the new `--ignore-lock` option with `fcm build`.

Extract system:

- The destination root directory is now locked while an extract is running. This prevents multiple instances of extract running in the same directory. However, you can bypass the lock if you specify the new `--ignore-lock` option with `fcm extract`.

Code management commands:

- `fcm merge` now supports custom and reverse modes.
- `fcm merge` now allows automatic merges in sub-trees if it is safe.
- `fcm merge` now handles automatic merges from sibling branches that are created at different revisions of the parent.
- `fcm branch, fcm diff --branch` and `fcm merge` can now handle creation, diff and automatic merge of a branch of a branch.
- `fcm switch` is improved to allow safer switches of your working copy to point to different branches in your project.
- `fcm commit` now displays your location in the branch, and extra warning when you are committing to the trunk of a project.
- New `fcm mkpatch` command.

General:

- Error handling is improved.
- The User Guide is now complete, with a much improved tutorial.
- New document: Fortran coding standard for FCM.

## Minor Enhancements & Bug Fixes

Build system:

- Ignore empty Fortran source files, so that alternate sections can be handled correctly.
- Handle recursive header file dependency correctly in pre-processing stage.
- Identify changes in pre-processed source file, the pre-processor options and keys correctly in incremental builds.
- Improve speed of pre-processing in incremental builds by not performing any unnecessary null-action pre-processing.
- Load archiver no longer includes main program objects.
- It is now possible for a sub-package to exclude particular types of dependencies.

Extract system:

- Sub-directories are now extracted with the non-recursive mode of `svn export`.
- Peg revisions should now be handled correctly in INC extract declarations.
- The command should now fail if a declared source directory does not exist or if the update of an extract destination fails.

Code management commands:

- `fcm branch --info` and `fcm diff` can now take a `PATH` as an argument.
- The `--ticket` option of `fcm branch --create` can now accept multiple tickets.
- `fcm branch --info` and `fcm diff --branch` should now work correctly in a sub-tree of a branch.
- `fcm branch --create` no longer offers to checkout the branch.
- `fcm commit` no longer fails when adding a new symbolic link.
- The `--password` option is now supported by the `fcm branch --create`, `fcm branch --delete`, `fcm commit` and `fcm delete` commands.
- Empty arguments to code management commands are now parsed correctly.
- The `fcm diff --graphical` option no longer fails with binary files.
- FCM will always set the environment variable LANG=en_GB before running Subversion commands. This prevents failure of FCM when it attempts to parse output from Subversion commands when a different LANG setting is used.

General:

- Various other very minor enhancements and bug fixes.

## System Requirements

### Perl

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:

- Carp
- Cwd
- File::Basename
- File::Compare
- File::Find
- File::Path
- File::Spec::Functions
- File::Spec
- FindBin
- Getopt::Long
- POSIX

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

- File::Temp
- Getopt::Long
- HTTP::Date
- XML::DOM

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

- Tk::ROText
- Tk

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.

### Subversion

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

- FCM makes extensive use of peg revisions in both the code management and extract systems. This requires Subversion 1.2.0.
- At the Met Office we are currently using Subversion 1.3.2 (although 1.2.3 was used until very recently).

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.

### Trac

The use of Trac is entirely optional (although highly recommended if you are using Subversion). At the Met Office we are currently using version 0.9.6.

### Other Requirements

The `fcm diff --graphical` and `fcm conflicts` commands require xxdiff. At the Met Office we are currently using version 3.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 9 and Red Hat Enterprise 2.1 and 4.4) and HP-UX 11.00.

## Installation

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.

- `doc/release_notes/` contains these release notes. It also contains the release notes for all previous versions which may be useful if you have skipped any versions.
- `doc/user_guide/` contains the FCM User Guide in both HTML and PDF form.
- `doc/design/` contains the FCM Detailed Design document (currently in draft form).
- `doc/standards/` contains the FCM Perl and Fortran coding standards. The Perl standard describes the standards followed by the FCM code. The Fortran standard contains some specific advice on the best way of writing Fortran code for use with FCM as well as more general advice on good practise.

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 file `tutorial/repos/tutorial.dump` should be loaded into an empty repository using the `svnadmin load` command.
- The hook scripts in `tutorial/hook/` should then be installed in this repository in order to prevent any commits to the trunk. Note that the configuration file `svnperms.conf` assumes that the tutorial repository is called `tutorial_svn`. Please edit this file if you use a different name.
- The repository should be configured to allow users write access. You may find it easiest to simply allow anonymous access.
- A Trac system should be configured associated with the Tutorial repository. You then need to allow users write access. You may find it easiest to set up a number of guest accounts for this purpose.

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:

templates/hook/pre-commit
  This script restricts write-access to the repository by checking the following:
  - It executes the Subversion utility `svnperms.py` if it exists. This utility checks whether the author of the current transaction has enough permission to write to particular paths in the repository.
  - It checks the disk space required by the current transaction. It fails the commit if it requires more than 5Mb of disk space.
templates/hook/post-commit
  A simple post-commit hook script which runs the script `post-commit-background` in the background.
templates/hook/post-commit-background
  This script runs in the background after each commit.
  - It updates a `<repos>.latest` file with the latest revision number.
  - It creates a dump of the new revision.
  - It calls the script `background_updates.pl` if it exists.
  This script is installed as standard in all our repositories.
templates/hook/background_updates.pl
  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.
templates/hook/pre-revprop-change
  A simple pre-revprop-change hook script which runs the script `pre-revprop-change.pl`.
templates/hook/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.
templates/hook/post-revprop-change
  A simple post-revprop-change hook script which runs the script `post-revprop-change.py`.
templates/hook/post-revprop-change.py
  This hook script updates the Trac SQLite database following a successful change in the log message.
templates/utils/cron_template.ksh
  An example of how you might set up a cron job to make use of the `<repos>.latest` file.
templates/utils/daily_cron
  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.
templates/utils/fcm_add_trac.pl
  This script sets up a new Trac system and applies some configuration options which we use by default at the Met Office.
templates/utils/recover_svn.pl
  This script allows us to recover all of our Subversion repositories by using the nightly backups and the repository dumps.