Multi-Project Support for Trac

The current design of Trac associates one project to one environment.

More often than not, software projects tend to split themselves in separate sub-projects, sharing common libraries and components. In enterprise setups, it is practical to consolidate the development knowledge base in one Wiki, yet to be able manage the different products of family of products independently. Moreover developers are often working on different products at once, and would like to be able to have an overview of the different projects they're involved in, or at other times, would like to have the ability to focus on a single project.

Trac has to be adaptable to these working environments, and while InterTrac linking has been so far successful for relating resources from different Tracs to one another, the interaction and sharing of information couldn't go beyond that, so far.

In addition, the single project per environment design practically limits the number of projects that can be run concurrently, due to database resource sharing concerns.

The next step is therefore to provide the ability to group different Trac projects inside a single environment, so that the resources from one project become fully addressable from other projects or from a global level.

The main concept is that of a project identifier being attached to each resource, which provides an additional scope for the resource identifiers, in addition to the realm. The empty string '' could be used to qualify the toplevel project, which is always there. If no other project has been defined, then Trac behaves as usual, one environment is one project. As soon as other projects are defined, the environment becomes a multi-project one.

The Data Model

Independently from the GenericTrac specification, the MultiProject changes to the data model are quite simple. The only backward incompatible addition needed is a project field to most of the resource related tables.

An additional project table is also needed, and it can take the form of a resource table specialization from the GenericTrac. Projects should have at least a description field, an owner and a status field. Projects can be linked explicitly to shared data. For example, each projects can be linked to its own set of repositories.

For resource specific SQL queries, the appropriate project identifier will have to be specified in addition to the realm (if needed) and id information.

For SQL queries that may cover more than one project, a helper method can be used to form the include/exclude constraints, given the project pattern list that has to be used.

On the API side, the multiproject nature will be mostly transparent except when instantiating and manipulating resources, which will have an additional project field. Legacy resources and legacy code not taking the project into account will simply fallback to accessing resources at the global level, which will work just fine in single project environments.

Web User Interface Changes

There should be a few standard ways to switch the project, either a pull-down menu or a tab-bar (in the style of edgewall.org).

The toplevel project should also be able to present a Projects main navigation entries, showing a list of the available projects, much similar to the list of Milestones.

An admin module can be used to create new projects (eventually copying settings from another one), renaming projects and deleting them.

Existing modules that lend themselves to cover multiple projects should be adapted and provide a standard way to specify multiple projects when accessed from the toplevel project. This can take the form of a list of checkboxes, a multiple selection field, or a text field for entering a pattern. When those modules are accessed within a dedicated project (parameter 'project'), they should behave similarly to the single project Trac, i.e. not offer the possibility to cover different projects. But when the project is the toplevel one (project == '') or there are already multiple projects specified, then the possibility to select different projects should be offered.

Utilities

Scripts for importing and exporting projects between environments should be provided. This can be useful for archiving a project before deleting it, for merging multiple single environment Tracs into one, etc.

URL space for different projects

Several kinds of mappings can be defined for mapping URLs to projects, before normal request dispatching takes place. The two default ones are:

• host mapping: the name of the (virtual) host used to access the Trac environment is taken to be the name of the project. A given host can be configured to be an alias for the default, top-level project.
• prefix mapping: if the PATH_INFO starts with the name of a project, this will be taken to be the name of a project. If none such project is detected, then the request is targeted at the top-level project.

In addition to a single project specification, there can sometimes also be multi-project specifications in a given URL. The request parameter 'project' can contain more than one project, and if the request processor can take advantage of this, the scope of the request will cover those projects. The special value '*' can be used to cover all the projects and more generally can be used in a glob pattern to cover different projects at once, and a '!' prefix for a project name or pattern can be used to exclude those projects. Typical users of multi-project specifications are the Timeline, the Search, the Custom Query…

Data Sharing

As briefly mentioned above, some data structure will be accessible globally and are shared between project. This will be the case for the Version Control Subsystem, where the repositories and the associated data are global objects that can be accessed indifferently from different projects. Of course, projects can define which repository they want to cover, eventually none or just one. They can also specify which repository will be the default one for them (the reponame to use when no reponame has been explicitly specified in links or queries).

Session and user data will also be shared across different environments, to some extent: preferences at a global level can be overridden by preferences set at the project level.

Permission will also be shared, though the system of fine-grained permission can be used to limit the permissions to a given project.