"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

GeoNetwork RifCS Version Control

Introduction

SISS utilises Opensource GeoNetwork to create and publish metadata catalogue. ANDS collects and stores metadata in the RIF-CS format (see RIF-CS schemas). To transform the metadata into RIF-CS format, GeoNetwork implements a metadata converter from iso19139 to RIF-CS (geonetwork/xml/schemas/iso19139/convert/rif.xsl). ANDS harvests the metadata through OAI-PMH interface in GeoNetwork.


Each instance of rif.xsl varies between GeoNetwork due to different versions of GN and transformations required. When providing RIF-CS records to ANDS, for each records in geonetwork, there need to be an activity records describing how the data is collected, maintained etc. ISO19115 has no information for activities which is a mandatory element in collections. The current solution is to create manual activity records and link them to collections. The manually created activities is stored in geonetwork/xml/schemas/iso19139/convert/activities.xml. For each record in Geonetwork, an activity needs to be manually created. This solution was adopted at the time there were only few WxS harvesting nodes and no manually created iso19139 records in Geonetwork.

This results in multiple versions of rif.xsl and activities.xml which presents a problem of change management and makes it hard to keep track of changes/updates.

This guide documents how version control is implemented to these files.

Motivation for Version Control

As mentioned earlier, we have multiple files with the same names but slightly different content. We want a proper way of keeping track of changes and updates made to these files. With version control, we address the following issues:
  • We have projects that aim to publish clients' data to the outside world. This includes publishing the data catalog to ANDS. For example, BOM publishes weather data catalog through ANDS.
    • GeoNetwork is the software used to create metadata for the dataset that would be transformed and harvested into ANDS.
    • Different projects have different needs, therefore they may use different versions of GeoNetwork.
    • Presently, we support GeoNetwork versions 2.6.x (stable) and 2.7.x (trunk). The files used in the "patch" differs for the GeoNetwork versions.
  • Each project will have specific datasets, resulting in unique content for GeoNetwork records between projects.
    • Different XSL templates and activities.xml would be required to handle such differences.
  • In the past, the Rif-CS patches were attached to the WIKI pages ( 2.6.x and 2.7.x). It was hard keep track of the changes and updates this way.
  • Provided in this guide are instructions on upgrading GeoNetwork (2.6.x to 2.7.x). Version control would cater for such upgrades while ensuring their 2.7.x version will be the latest.

Subversion (SVN)

Subversion is an open source version control system. We use SVN to keep track of our file updates and changes. There's an existing repository for GeoNetwork. It has been redesigned based on the specification of this guide.

Repository Structure

The following is an example of what the folder/file hierarchy our repository will look like:

  • Trunk
    • 2.7
      • Readme.txt
      • Template (rif.xsl)
      • Template (activities.xml)
      • geonetwork_rif.patch
      • BoM
        • rif-cs.xml
        • activities.xml
        • geonetwork_rif.patch
      • Group 2
        • rif-cs.xml
        • activities.xml
        • geonetwork_rif.patch
    • 2.6
      • Readme.txt
      • Template (rif.xsl)
      • Template (activities.xml)
      • geonetwork_rif.patch
      • Auscope-Production
        • rif-cs.xml
        • activities.xml
        • geonetwork_rif.patch
      • Auscope-Test
        • rif-cs.xml
        • activities.xml
        • geonetwork_rif.patch
Notes:
  • README.txt - whenever a change is made to the templates or patch, update this file.
  • rif.xsl - For each new project/group, perform a SVN copy into the project's folder. This rif.xsl is an implementation of the template and is unique to its project
  • activities.xml - Similar to rif.xsl.
  • geonetwork_rif.patch - Patch which is applied to geonetwork source. Rebuild and deploy Geonetwork after patch is applied.
  • When a change is made to the patch or templates, updating to reflect these changes for all projects is linear. The following solution is feasible for us as we a manageable amount of projects/groups.

Use Cases

Making a Release

The following example depict the steps to be carried out for making BOM release:
  • Tag (Date + Version) on BOM folder.
  • Zip Release.
The above change is safe due to File ID stamping and SVN tagging.

Updating the Template

Update rif.xsl:
  • Check to see if an update is required.
  • If so, direct merge into project/rif.xsl.
  • Fix conflicts.
  • Update README.txt.
  • Commit changes.

Updating Client's Version

2.6 -> 2.7:
  • Copy template (SVN Operation).
  • Manual configuration/changes.
  • Update README.txt.
  • Commit changes.
Topic revision: r9 - 08 Aug 2012, RiniAngreani
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).