Changes between Version 3 and Version 4 of TracDev/Proposals/MultipleProject

Timestamp:

May 8, 2009, 11:04:02 AM (15 years ago)

Author:

Christian Boos

Comment:

Reworked the introduction

TracDev/Proposals/MultipleProject

@@ -3 +3 @@
 The current design of Trac associates one project to one environment.
 
-More often than not, software projects tend to split themselves in separate sub-projects, sharing common libraries and components. In enterprise setups, it is practical to consolidate the development knowledge base in one Wiki, yet to be able manage the different products of family of products independently. Moreover developers are often working on different products at once, and would like to be able to have an overview of the different projects they're involved in, or at other times, would like to have the ability to focus on a single project.
+More often than not, software projects tend to split themselves in separate sub-projects, sharing common libraries and components. In enterprise setups, it is practical to consolidate the development knowledge base in one Wiki, yet to be able manage the different products or family of products independently. Moreover developers are often working on different products at once, and would like to be able to have an overview of the different projects they're involved in. At other times, the same developers would like to have the ability to fully focus on a single project. Widening the scope and looking at a whole family of products or even at the entire set of projects is also useful when one wants to get an overview or doesn't know where to start searching for an information.
 
-Trac has to be adaptable to these working environments, and while InterTrac linking has been so far successful for relating resources from different Tracs to one another, the interaction and sharing of information couldn't go beyond that, so far.
 
-In addition, the single project per environment design practically limits the number of projects that can be run concurrently, due to database resource sharing concerns. 
+Trac has to be adaptable to these different views. The current approach of setting up different Trac environments only allows to get a fixed view on one project. By using InterTrac links, it has been possible to relate resources one to another across Tracs, but the interaction and sharing of information couldn't go beyond linking: no common search or ticket queries, no shared timeline, no possibility to conveniently move resources from one project to the next while retaining the full history, etc.
 
-The next step is therefore to provide the ability to group different Trac projects inside a single environment, so that the resources from one project become fully addressable from other projects or from a global level.
+In addition, for some database backends, the single project per environment design impose practical limits to the number of projects that can be run concurrently, due to connection sharing concerns (#8058). 
+
+The next step is therefore to provide the ability to create multiple Trac projects and sub-projects inside a single environment and to offer some convenient ways to form "views" on which projects should be active for a given request.
+
+In our usual tradition of backward compatibility, when an environment only contains the toplevel project everything should continue to work like it always did. This will allow alternate implementations of multiple project setups to continue working unmodified (see the various TracMultipleProjects sub-pages).