= 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. This is unlikely 
to happen in the short term. 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).

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 [http://lists.edgewall.com/archive/trac/2005-May/002932.html this mail]
for some additional explanations.

=== 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
   [source:branches/cboos-dev/xref-branch xref-branch] 
   and the [source:branches/cboos-dev/trac-obj-branch 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'').