How RForge works
consists of various components that are provided for developer's convenience and can be combined in many ways. This document describes the various components and conventions that allow you to use it for your project in the most suitable way.
The basis for each project is a SVN repository that holds both the current project and its associated webpages. Each repository has the following standard layout:
- /trunk - project main trunk
- /branches - place to put branches
- /tags - place to put tags
- /web - place for web-content
- /files - place for custom files
So for example for a project foo
you can check out the current trunk using:
svn co svn://svn.rforge.net/foo/trunk foo
Then you work on it, modify or add files and commit it. At the time of the commit RForge will check the package and create its documentation if it is told to, see details below.
Note: RForge.net now supports external GIT repositories as well - use the "Modify Your Project" item under "Other actions""Modify Your Project" to set the GIT URL. In that case the SVN sources are ignored and the check process pulls from a git repository. You can use WebHook http://rforge.net/do/githook in GitHub or GitLab to have check-on-commit enabled. Note that the project name in RForge.net must match the git repository name exactly.
The project webpages are fetched from the /web part of project's SVN repository. Webpages intended for viewing should be placed directly in the /web space and should have .html extension. They are embedded in the RForge look and feel. In addition, special directives of the form %XXX% are replaced dynamically, where XXX is one of the variables or commands supported by RForge (see below). Any subdirectories are directly served and can be used for static content. See customizing webpages below for further details.
RForge provides automatic checking and building of R packages and supporting documentation. There are two ways to use this facility:
- simple R packages
If your project consists entirely of an R package without any pre-processing needs or additional files, then the repository should simply contain the package as it is to be distributed. This implies that there must be a DESCRIPTION file in the root of the project. This will cause RForge to check the package, create a snapshot and documentation on each commit automatically. The snapshot is also immediately available from the RForge R repository.
- package with developer files or complex project containing a package
If you have additional files in your project repository that you don't want to include in the package or if the package is only a part of your project, you can use a shell script 'mkdist' in your project root to create a distribution tar-ball which will be subsequently used as the deployed package. This gives you absolute flexibility in how the package source tar-ball is created from your repository sources - the project trunk doesn't have to be of any specific form for this to work. See a sample script below for a very simple use or other projects such as rJava for more elaborate apporaches (e.g. running autoconf etc.). There are two requirements to keep in mind when writing the custom mkdist script:
If a project contains a NEWS file in its repository root then it is accessible (in beautified form) as "News" menu item. It is assumed to be in a form similar to R's NEWS file, but any format will do.
RForge attempts to keep a common look and feel so users don't need to deal with different UIs. Also this simplifies the maintenance for the developers, because menus etc. are generated automatically. A project is free to use external webpages if it desires (see project administration). When using RForge's content management facilities each .html file in the web root can use following special directives:
%NAME% - name of the project
%TITLE% - project title
%VER% - package version (from DESCRIPTION or version script)
%RForge.svn.log% - last SVN (or GIT) log entries
%RForge.pkg.desc% - main fields from the DESCRIPTION file in tabular form
%RForge.news% - NEWS file from the package
In addition you can create a special file called map which defines the menu on the left hand side. The format for each custom entry is page.html|Menu item where page.html is the web page filename and Menu item is the text that shall appear in the menu (you can use HTML). In addition, you can use standard entries that start with a plus. The following is the contents of the default map file:
# default menu
When creating your own map file, you can combine any custom entries and default entries. In addition you can use special entries . (just a dot on a line), - (minus on a line) for space or vertical bar respectively and =|.. where .. can be any HTML code that will be inserted as-is.
Remember that only files in the web root are processed, all other files are passed as they are.
RForge offers optional e-mail accounts and aliases at RForge.net to registered developers. The RForge mail server includes virus scanner, spam filter and web-mail interface (the latter only with accounts, not aliases).
RForge optinally provides Bugzilla to all projects that wish to use it. Use project administration page to enable bugzilla for your project. This basically registers your account with bugzilla and creates a product with your project name. Since this Bugzilla setup is global, users reporting bugs need to register only once to report bugs to any RForge projects.
RForge optimally provides mailing lists to all projects that wish to use it. The list server is lists.rforge.net. If you want one or more lists for your project, they must start with your project name and you will be made administrator of the mailing lists.
The entire RForge (SVN, projects, repository, code ...) is backed up daily to two other servers located in the USA and Germany. Both are in locations separate from the main server. The main server and both backup servers are running on server-grade hardware with RAID. One of the backup servers can be used as a replacement for the main server in case of a hardware failure and the other one runs in a highly-protected environment for security audits.
If you have any suggestions on how to improve RForge, please don't hesitate to drop me a line firstname.lastname@example.org, Simon Urbanek.