| | 1 | [[PageOutline]] |
| | 2 | = A Comprehensive Multi-Project Solution = |
| | 3 | |
| | 4 | ''Abstract:'' we present a comprehensive solution for many of the problems of maintaining or participating in multiple projects under Trac. We briefly analyze some of the other approaches and explain why we're not using them. |
| | 5 | |
| | 6 | > '''Note 1''': this page is a work in progress. I've solved the technical |
| | 7 | > issues on my local development server and am composing this page as I |
| | 8 | > port my real Trac instances over to the new system. |
| | 9 | |
| | 10 | > '''Note 2''': the solutions on this page require the use of |
| | 11 | > not-yet-released versions of Trac, Genshi, and several plugins, available |
| | 12 | > from those projects' Subversion repositories. |
| | 13 | |
| | 14 | |
| | 15 | == Just How Comprehensive Is This Solution, ''Really?'' == |
| | 16 | |
| | 17 | Ticket [#130] contains a long, rambling, and extremely enlightening discussion of what people need from MultiProject support. Anyone who has read that thread and the [TracMultipleProjects other pages] proposing different ways to support multiple projects knows that my solution isn't going to work for everyone. Nonetheless, I think I've hit a "sweet spot" that gives most people most of what they're looking for, and more importantly, can be (relatively) easily set up today by anyone. So while my claim of having a "comprehensive" solution might be seen as grandiose, I think it's supportable. |
| | 18 | |
| | 19 | == Motivation == |
| | 20 | |
| | 21 | When you host multiple trac projects, its very common to have users that are members of more than one of these projects. If, like [http://boost-consulting.com/about/people me], you're using your Tracs to support multiple customers, you probably need to be a member of each trac instance. |
| | 22 | |
| | 23 | It doesn't work to ask our customers to [TracMultipleProjects/SingleEnvironment share the same Trac instance]. Customers need privacy, and Trac isn't yet up to the task of [TracDev/SecurityBranch manageing fine-grained permissions] on individual [WikiContext resources]. Sometimes we're working on proprietary software that ''must'' be kept private, but even when we're working on open source, customers generally feel more comfortable when their issues are not exposed to the world. |
