Overview
The
io7m-jfprop package implements a
simple system for keeping
Fossil
repositories up-to-date and synchronized with remote servers.
The main use case is that of synchronizing private
(but "
canonical") repositories with a public mirror.
An organization,
ExampleCorp, using
Fossil
may have something approximating the following configuration:
The server at fsl.iw.example.com acts as the
so-called canonical repository. That is, it's
the repository that's considered to be the authoritative source for the project.
In the example above, fsl.iw.example.com is
a server that's private to the ExampleCorp organization,
with the red line indicating the boundary of the ExampleCorp
private network.
Developers in the organization have clones of this
repository on each of their workstations (c0.iw.example.com,
c1.iw.example.com, etc). Each time a developer
makes a change to his/her own clone of the repository, the clone is automatically
synchronized with the remote
of the clone (fsl.iw.example.com), pushing
new changes to the remote and pulling any changes received by the remote since the
last synchronization. Consequently, changes made by each developer are gradually
propagated to each other developer, and the fsl.iw.example.com
repository.
The organization then decides to create a public mirror
of the repository, hosted on fossilhub.com. This
mirror repository may or may not allow commits and tickets to be created by
external contributors. The fossilhub.com
repository is the remote of the
fsl.iw.example.com repository. The problem
here is that when a developer makes a change to their own clone and synchronizes
with fsl.iw.example.com, this will
not cause fsl.iw.example.com
to synchronize with fossilhub.com. The effect of
this is that the fossilhub.com repository will
drift further and further out of date with respect to
fsl.iw.example.com, unless a developer manually
logs into the fsl.iw.example.com server and
synchronizes the repository with fossilhub.com.
Also, if external contributors are allowed to make
changes to the fossilhub.com repository, these
changes will not reach fsl.iw.example.com (and
by extension, each of the ExampleCorp developers)
until the next time that fsl.iw.example.com is
manually synchronized.
The io7m-jfprop package attempts to
implement a simple server to help alleviate the above problem.
The fossil program can be configured to run
small pieces of code written in the TH1
scripting language whenever the person using the program performs a commit,
or creates/edits a ticket. The scripting language is capable of making HTTP(S)
requests. The io7m-jfprop package
implements a server that listens for HTTP(S) requests, and synchronizes
repositories with their own remotes when requests appear. Essentially, each
developer configures their own clone to send a request to the
io7m-jfprop server listening
on fsl.iw.example.com each time they
commit, and the listening server then synchronizes the
fsl.iw.example.com repository with
fossilhub.com. The
io7m-jfprop server can also
be configured to contact other
io7m-jfprop servers when this
occurs, to propagate changes to repositories that are even further removed
. As an example: