[ Home | Main Table Of Contents | Table Of Contents | Keyword Index ]

fx_example_peer_fossil(n) 1 doc "FX - Extended Fossil Management"

Name

fx_example_peer_fossil - fx - Example of mirroring with fossil peers.

Table Of Contents

Synopsis

  • package require Tcl 8.5

Description

Welcome to fx, an application and set of packages providing extended management commands for the fossil SCM. This is an introductory document to fx, an application with supporting packages providing users of the Fossil SCM with extended management facilities going beyond the regular command line.

It is one in a set of related examples demonstrating the abilities of the system. The interested reader can then go on into to reference documentation via fx - Introduction to fx.

Background to the Example

  1. You have to manage multiple fossil mirrors of your repository, of at least their content, and possibly their configuration as well.

    The example assumes multiple, because a single mirror can be handled by fossil itself, setting it as the repository's remote.

  2. You have (full) access to a repository file of the project.

  3. You have (full) web access to the mirrors of the project.

Solution to the Example

Setting up

The main point in setting up the mirroring to other fossil repositories of the same project is to tell the local repository (file) where the mirrors are, and what to do with them, i.e. do we push, pull or sync data, and what areas do we exchange with them.

A few examples:

	fx peer add push content http://foo
	# push regular (non-configuration) data to the peer given by the url.
	# IOW commits, tickets, wiki pages, etc.
	fx peer add pull skin http://foo
	# push the configuration area 'skin' from the peer
	fx peer add sync email http://foo
	# synchronize the configuration area 'email' with the peer.

Many peers are possible, each with a different set of areas to exchange and per-area directions.

Go

With all the preparatory work finally done we can go and start the mirroring. Note however that fx does not fully do everything by itself.

It assumes that it will be called from a cron job, i.e. that all the timing-related things are handled by the system, as is the prevention of multiple parallel mirroring runs, and where log files will be located.

As we have full access to the fossil repository file of the project the only fx command we need in the core job script is peer exchange, i.e.

    fx peer exchange -R /path/to/the/fossil/repository/file

A few things to remember however:

  1. cron is notoriously fiddly with regard to the environment variables provided to the jobs. Make sure that:

  2. Your PATH provides access to fossil.

  3. That a proper USER variable is set for fossil to pick up. Or that it is specified in the peer url(s).

More examples

  1. fx - Example of mirroring to git peers.

Bugs, Ideas, Feedback

This document, and the package it describes, will undoubtedly contain bugs and other problems. Please report such at the fx Tracker. Please also report any ideas for enhancements you may have for either package and/or documentation.

Keywords

fossil, scm

Category

Fossil support