Changes between Version 1 and Version 2 of TracMultipleProjects/SingleEnvironment

Timestamp:

May 6, 2005, 2:49:14 PM (19 years ago)

Author:

Christian Boos

Comment:

Added some details about different implementation ideas

TracMultipleProjects/SingleEnvironment

@@ -39 +39 @@
 (Subversion) repository, in a single Trac environment.
 
-== Possible implementation ==
+== 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.
+the already existing ''component'' ticket field could be 
+used to represent a project. 
 
-cboos explained in ticket #586 (although that ticket belongs to the
-other multiple component support ''family'') how this could
-be implemented using the experimental relationship facility introduced 
-in the source:branches/cboos-dev/trac-obj-branch branch.
+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.
 
-''more explanations to come...''
+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'').