Changes between Version 4 and Version 5 of TracMultipleProjects/SingleEnvironment
- Timestamp:
- Feb 7, 2007, 10:42:22 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracMultipleProjects/SingleEnvironment
v4 v5 9 9 Trac environment, in order to have a unified view on 10 10 the development activity. 11 12 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. 13 14 Referencing resources located in one project from another project can be done in both cases by using InterTrac links. See WikiContext for details. 11 15 12 16 … … 27 31 The oldest ticket presenting this approach is #130. 28 32 It asked for being able to browse multiple projects 29 residing in different repositories. One of the problems this 30 would raise is the ambiguity it introduces in TracLinks 31 (however, the InterTrac approach, explained in 32 TracMultipleProjects/MultipleEnvironments could be extended to 33 adapt to this situation too, see #2086). 33 residing in different repositories. 34 34 35 35 Since then, other people have expressed in #130, #548 and also very … … 38 38 (Subversion) repository, in a single Trac environment. 39 39 40 == Possible implementations == 40 The implementation details of multiple repository support are more 41 specifically addressed by #2086 and the discussion in 42 VcRefactoring#SupportforMultipleRepositories. 41 43 42 == = Using a project field ===44 == Proposed Implementations == 43 45 44 Within one database, a {{{project}}} scope could be added 45 to the Trac objects, in addition to their {{{type}}} and {{{id}}}. 46 In GenericTrac, I proposed some kind of unification of the underlying data model 47 for Trac resources. 48 49 I think this refactoring is also a good opportunity to introduce support for 50 multiple projects within a single environment. 51 52 === Using a `project` field === 53 54 Within one database, a `project` scope could be added 55 to the Trac objects, in addition to their `realm` and `id`. 46 56 47 57 See [http://lists.edgewall.com/archive/trac/2005-May/002932.html this mail] 48 for some additional explanations. 58 for an early introduction of this idea. 59 Also see TracMultipleProjects/ByProductAndSearch for a follow-up. 49 60 50 Also see TracMultipleProjects/ByProductAndSearch for a writeup of this idea. 61 This plays also well together with the WikiContext introduced in [milestone:0.11]. 62 The pervasive use of contexts as lightweight ''descriptors'' of resources will 63 also allow to transparently carry around the notion of the "current" project. 51 64 52 === Using Component objects === 65 That way, most of the current Trac code will remain unchanged, 66 and one of the principal objection against the use of a `project` field which 67 (having to pass yet another argument in addition to `req` and `db` to most of 68 the methods), is now addressed. 69 70 === Project resource === 53 71 54 72 The ticket #1048, as well as ticket #1135, suggest that … … 56 74 used to represent a project. 57 75 58 But currently, a ''component'' is nothing more than an enumeration,59 and even if one could attach more information to a component 60 in the {{{trac.ini}}} (as #1135 does), this would not be very flexible.76 But the notion of component is already well associated now 77 to some specific subsystem, a part of a project. 78 There are even requests for adding ''sub''-components (#548). 61 79 62 A component could be instead a new kind of Trac object, with 63 a few specific fields, like the list of Source objects 64 (repository paths) that contain the source code of the component 65 (see TracObjectModelProposal). 80 So why not introduce a new toplevel `project` realm, which 81 will be used to refer to projects as full-blown Trac resources? 66 82 67 Tickets or milestones could also be associated to one or 68 more components, using relationships (see TracCrossReferences). 83 A project resource deserves a description and its related functionality 84 (history, diffs, change notifications ...), probably attachments as well, 85 and could be used to display a few statistices (... #1). 69 86 70 This would enable to filter the timeline events by a list 71 of components, and only showing events about changesets or 72 tickets that are related to them. 87 === Open Questions === 73 88 74 a follow-up idea would be to have ''User'' Trac objects, 75 corresponding to each developer in the team. 76 Those objects could have relations like __owns__, or __works-on__ 77 to the Component objects. 89 ==== What about Global or Shared Resources? ==== 78 90 79 The default set of components used for filtering could be those 80 associated to the user by the way of its user page. 91 Though by default any resource would be associated to some specific project, 92 it would be interesting to get the ability to create resources that are global 93 to all projects, or if a more fine grained control is needed, resources could 94 be attached to multiple projects. 81 95 82 Of course, at this point, there are a lots of missing pieces in this 83 picture: 84 * the relations and the trac objects are only in their infancy in the 85 [source:branches/cboos-dev/xref-branch xref-branch] 86 and the [source:branches/cboos-dev/trac-obj-branch trac-obj-branch] 87 * some additional design is described in the TracObjectModelProposal, 88 * and a few things are yet to be invented, but you get the idea (I hope!) 96 Typical example would be ''User'' resources (see #2456), as a User could 97 typically work on several projects, and when accessing a User page (#150), 98 it would be interesting to get the ticket statistics the same way one can 99 get the ticket statistics for a given milestone on the corresponding 100 milestone page. 89 101 90 This approach was initially introduced in ticket #586 91 (although that ticket belongs to the other multiple component support 92 ''family''). 102 103 ---- 104 See also: TracMultipleProjects, GenericTrac, WikiContext
