Multiple Projects within a Single Trac Environment

This is an alternative conception about how to manage multiple projects with Trac. The traditional way is to follow the model of TracMultipleProjects/MultipleEnvironments.

Yet there has been since a long time many request for being able to manage multiple projects within a single Trac environment, in order to have a unified view on the development activity.

Possible motivations for having a single Environment

• one single wiki, which facilitates the building of shared knowledge (development guidelines, development process documentaion, tips and tricks, customer information, etc.)
• possibility of sharing Milestones between projects (useful for coordinating a single release of different applications)
• sharing tickets between projects, and moving them between projects

One or Multiple Repositories?

The oldest ticket presenting this approach is #130. It asked for being able to browse multiple projects residing in different repositories. One of the problems this would raise is the ambiguity it introduces in TracLinks (however, the InterTrac approach, explained in TracMultipleProjects/MultipleEnvironments could be extended to adapt to this situation too, see #2086).

Since then, other people have expressed in #130, #548 and also very clearly in #1048, that it would already be a big step ahead to support multiple projects located within a single (Subversion) repository, in a single Trac environment.

Possible implementations

Using a project field

Within one database, a project scope could be added to the Trac objects, in addition to their type and id.

See ​this mail for some additional explanations.

Also see TracMultipleProjects/ByProductAndSearch for a writeup of this idea.

Using Component objects

The ticket #1048, as well as ticket #1135, suggest that the already existing component ticket field could be used to represent a project.

But currently, a component is nothing more than an enumeration, and even if one could attach more information to a component in the trac.ini (as #1135 does), this would not be very flexible.

A component could be instead a new kind of Trac object, with a few specific fields, like the list of Source objects (repository paths) that contain the source code of the component (see TracObjectModelProposal).

Tickets or milestones could also be associated to one or more components, using relationships (see TracCrossReferences).

This would enable to filter the timeline events by a list of components, and only showing events about changesets or tickets that are related to them.

a follow-up idea would be to have User Trac objects, corresponding to each developer in the team. Those objects could have relations like owns, or works-on to the Component objects.

The default set of components used for filtering could be those associated to the user by the way of its user page.

Of course, at this point, there are a lots of missing pieces in this picture:

• the relations and the trac objects are only in their infancy in the xref-branch and the trac-obj-branch
• some additional design is described in the TracObjectModelProposal,
• and a few things are yet to be invented, but you get the idea (I hope!)

This approach was initially introduced in ticket #586 (although that ticket belongs to the other multiple component support family).