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.
Progress on this topic (or lack of it) is tracked in #11025.
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
- sharing permissions between projects so that a common team may engage multiple projects without duplicating the permissions table
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.
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.
Within one database, a
project scope could be added
to the Trac objects, in addition to their
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
db to most of
the methods), is now addressed.
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).
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.
Currently, TH:SimpleMultiProjectPlugin implemented the ability of having multiple projects with one Trac instance. The basic idea was to use a custom ticket field
project, and to add new tables to the Trac database for mapping milestones, components and versions to appropriate projects. The timeline and roadmap view got an additional filter for certain projects. The "New ticket" form offers only the versions and milestones for the chosen project.