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 or 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. At other times, the same developers would like to have the ability to fully focus on a single project. Widening the scope and looking at a whole family of products or even at the entire set of projects is also useful when one wants to get an overview or doesn't know where to start searching for an information.

Trac has to be adaptable to these different views. The current approach of setting up different Trac environments only allows to get a fixed view on one project. By using InterTrac links, it has been possible to relate resources one to another across Tracs, but the interaction and sharing of information couldn't go beyond linking: no common search or ticket queries, no shared timeline, no possibility to conveniently move resources from one project to the next while retaining the full history, etc.

In addition, for some database backends, the single project per environment design impose practical limits to the number of projects that can be run concurrently, due to connection sharing concerns (#8058).

The next step is therefore to provide the ability to create multiple Trac projects and sub-projects inside a single environment and to offer some convenient ways to form "views" on which projects should be active for a given request.

In our usual tradition of backward compatibility, when an environment only contains the toplevel project everything should continue to work like it always did. This will allow alternate implementations of multiple project setups to continue working unmodified (see the various TracMultipleProjects sub-pages).

The Data Model

The main idea is to attach a project identifier to each resource.

This can be achieved either by using an extra .project field for each resource or by parenting the resources in a project resource. The second way is probably better, as some resources might be project independent (like the Changeset and Source which belong to a given repository - see MultiRepos).

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.

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.