# --- 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 flexBelow are detailed comments on some of these fields.
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:
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.