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.

Note that the two approaches are actually complementary. In some situations it will make sense to go with multiple environments, in some others, keeping all projects in a single environment would be preferred.

Referencing resources located in one project from another project can be done in both cases by using InterTrac links. See WikiContext for details.

Possible motivations for having a single Environment

• one single wiki, which facilitates the building of shared knowledge (development guidelines, development process documentation, 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.

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.

The implementation details of multiple repository support are more specifically addressed by #2086 and the discussion in VcRefactoring#SupportforMultipleRepositories.

Proposed Implementation

In GenericTrac, I proposed some kind of unification of the underlying data model for Trac resources.

I think this refactoring is also a good opportunity to introduce support for multiple projects within a single environment.

Using a project field

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

See ​this mail for an early introduction of this idea. Also see TracMultipleProjects/ByProductAndSearch for a follow-up.

This plays also well together with the WikiContext introduced in 0.11. The pervasive use of contexts as lightweight descriptors of resources will also allow to transparently carry around the notion of the "current" project.

That way, most of the current Trac code will remain unchanged, and one of the principal objection against the use of a project field which (having to pass yet another argument in addition to req and db to most of the methods), is now addressed.

Project resource

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

But the notion of component is already well associated now to some specific subsystem, a part of a project. There are even requests for adding sub-components (#548).

So why not introduce a new toplevel project realm, which will be used to refer to projects as full-blown Trac resources?

A project resource deserves a description and its related functionality (history, diffs, change notifications …), probably attachments as well, and could be used to display a few statistices (… #1).

Open Questions

What about Global or Shared Resources?

Though by default any resource would be associated to some specific project, it would be interesting to get the ability to create resources that are global to all projects, or if a more fine grained control is needed, resources could be attached to multiple projects.

Typical example would be User resources (see #2456), as a User could typically work on several projects, and when accessing a User page (#150), it would be interesting to get the ticket statistics the same way one can get the ticket statistics for a given milestone on the corresponding milestone page.

---

See also: TracMultipleProjects, GenericTrac, WikiContext