= Multiple Projects using Multiple Trac Environments = This is the traditional way of handling multiple projects with Trac: create a new environment for tracking a given software project. That way, each project is managed independently from the others. This can be achieved using mod_python and tracd. Further technical documentation about the setup can be found in TracMultipleProjects. A use case is described in this [comment:ticket:2639:2 comment]. This page is for discussing open points related to using multiple environments for managing multiple projects, and for contrasting this approach to an alternative approach described in TracMultipleProjects/SingleEnvironment. (This multi-project structure is explicitly not part of #130.) MikeC sez: OK, I'm discussing. I find two things onerous about the current support for multiple projects. As described in the comment cited above, our multiple projects are separate (different customers). The project directory structure here lends itself to using similar paths: `\\server\projectID\Software\Trac` would be ideal for each projectID on the server -- but the current implementation would not see the second directory. This is an annoying restriction, and I don't see a good reason for it. As it is, I need to name each environment's directory with a unique label. The other onerous thing is having to specify each environment on the tracd command line -- under Windows with the standalone server, this requires editing the registry to add (or remove) a new project environment, and not only does the list get unwieldy but it can easily grow to be too long to be accepted under Windows. At the least, tracd should accept a file that contains the list of environments. Better would be a putting the environment list inside the Trac.ini file of the default (master) environment. Best would be adding an admin control panel to add and remove environments dynamically. I've opened #9433 to address the above. 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. == One or Multiple Repositories? == It is straightforward to manage multiple repositories using this approach: as each environment is based on a given (Subversion) repository, simply create an environment for each repository, as required. However, there are two situations that are quite common and are currently not well addressed: 1. the different repositories are within the same company or team (e.g. one repository for some legacy application, one for new applications, one for the common components, ...) and there is a need to have some kind of integration between the projects * Expressed in #234, a proposed solution was to introduce the InterTrac extension for TracLinks. 1. there's only one repository actually, containing many projects * First expressed in #586, having been reiterated several times since (#1025, #1059, #1398). Since [1413] (the new ''versioncontrol'' layer), there is actually support for working on a subset of a repository, It is however planned to add support for multiple repository within a single project (#2086), so that the current requirement to use multiple environments when having multiple repositories will be lifted. You can also use a system like git, which handles decentralized development quite well. == Aggregate Reports == Since each project has its own database, it's difficult to get an overview of activity for all (or a set of) projects. One option to help with this is TracMultipleProjects/MultipleEnvironmentsSingleDatabase ---- See also: TracMultipleProjects, TracHacks:TracForgePlugin, VcRefactoring#SupportforMultipleRepositories