repo.hu config

Each repository hosted at repo.hu should have a config file that describes the repository release processes. This is a plain text file called "repo.hu" in the root of the repository. The following example specifies all possible fields - most projects will need only a subset of them. 
# --- directories & files ---
# file paths are relative to the $tags/$package/$version directory
# or $tags/$version (depending on multipackage)

# watch this directory for new tags; tags are used to generate releases
# tags should be called version numbers only, like "1.0.2", not
# "project-1.0.2". Format of the version number is up to the developers;
# they will be numerically sorted in reverse order before they are listed.
# [absolute path]
tags=tags/

# do we have multiple packages?
multipackage=0

# release notes file (not mandatory)
relnotes=Release_notes

# changelog file (not mandatory)
changelog=Changelog

# documentation dir (relative to the tag). If specified, for each release
# a snapshot of this directory is created and linked from the releases
# page. The directory content will be listed if index.html does not present.
# [relative path]
doc=doc

# project page (absolute path)
# [absolute path]
web=trunk/doc

# --- source release formats (none of them is mandatory) ---
rel_src_targz=1
rel_src_tarbz2=1
rel_src_zip=1

# --- display properties for source releases ---
# how many past releases to display on the main page?
display_releases=4

# === build related settings ===
# which directories to check out for a build
# by default, if this field is not set, /trunk is used
# [space separated list of absolute paths]
build_checkout=trunk vendor

# --- binary release formats (none of them is mandatory) ---
# debian/ for building Debian packages. Multiple directories can be
# specified, spearator is space.
# [space separated list of absolute paths]
debian=trunk/dir1/debian trunk/dir2/debian

# tpm/ for building rpm packages. Multiple directories can be
# specified, spearator is space. Paths are absolute.
# [space separated list of absolute paths]
rpm=trunk/dir1/rpm trunk/dir2/rpm

# --- build dependencies ---
# list of package names separated by space - these need to be installed
# on the build server in order to build the package
# [space separated list of package names]
builddep=make gcc bison flex
Below are detailed comments on some of these fields.

rel_src_*

The value of these fields are either 1 or anything else.

web

If not commented out, this directory is used as the project web page. Whenever any change is committed under this directory, the project web page is svn upped from this dir. This directory can not contain file or directory named "releases", as that's the directory where automatic releases are created.

multipackage

Most projects can be released as a single tarball. This is the "multipackage=0" model. In this case the developer copies trunk/ to tags/VERSION (for example "svn copy trunk ../tags/1.0.3"). The release page features a single table with the latest display_releases releases listed in reverse order (latest release on top). The server determines version number from directory names under tags/.

Sometimes a repository is a collection of loosely related projects and releasing the whole bunch together is not reasonable. Instead, splitting trunk/ in packages and releasing packages one by one is better. In this case multipackage should be set to 1 and tags/ structure must be tags/PACKAGE/VERSION. An example of such a tags tree:

tags/foo/1.0.0 tags/foo/1.0.1 tags/foo/2.0.0 tags/bar/0.8 tags/bar/0.9 tags/bar/1.0 tags/bar/1.1 tags/bar/1.1b This repository has two packages, one called foo, the other called bar. Note that packages may have different versioning scheme. Also note that repo.hu doesn't want to know about where packages are coming from, or in other words how trunk/ is structured. It is the responsible of the developers to copy the right directory from trunk to tags.

Web, source releases and binaries

These are three different things which may evolve in different pace. Repo.hu doesn't try to mix them - if the developer does a source release, binaries are not built and vice versa, when binaries are rebuilt, no source release is created. Optional web page is the 3rd independent factor, that may change much more often than source or binary releases are done.

If the project admin wants to keep source and binary releases in sync, he needs to do it client-side: commit all binary package changes and a tag in the same changeset, keep tag version in sync with binary package version number. With repo.hu it is very simple to automatize processes - a Makefile rule or a tiny shell script could do this all, including the commit.