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.
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.
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.
Plugin solution
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.
See also: TracMultipleProjects, GenericTrac, WikiContext
