[Trac-tickets] Re: [The Trac Project] #586: patch to allow trac to operate on repository subset for multi project repositories

The Trac Project noreply at edgewall.com
Mon Apr 4 05:17:31 EDT 2005


#586: patch to allow trac to operate on repository subset for multi project
repositories
-------------------------+--------------------------------------------------
       Id:  586          |      Status:  assigned                
Component:  general      |    Modified:  Mon Apr  4 05:17:26 2005
 Severity:  enhancement  |   Milestone:  0.9                     
 Priority:  normal       |     Version:  0.7.1                   
    Owner:  cboos        |    Reporter:  hazmat at objectrealms.net 
-------------------------+--------------------------------------------------
Changes (by cboos):

  * status:  new => assigned
  * owner:  jonas => cboos

Comment:

 I also have astrong interest on that topic, because our main Trac
 environment
 is based upon one big Subversion repository, which, in the short term,
 will contain all the code for all our projects (which is a good thing
 because we have a lot of shared components).

 It will soon be a requirement to provide our developers with an easy
 way to filter the components in which they are interested in.
 That would typically be 1 or 2 applications, and several common
 libraries.

 I have some ideas about how to implement this feature. This would
 require the relationship facility found in the
 [source:branches/cboos-dev/trac-obj-branch trac-obj] branch.

 The heart of the solution would be based on ''Component'' pages,
 which are wiki page that have a __is-a__ relation to the
 ''ComponentTemplate'' page (i.e. the page was created using
 that template, see #1376).

 That page would be related to specific Source objects
 (directories or files, see changeset:1486#file1) that
 will be used to filter in the changesets affecting
 this component.

 Additionally, those component pages will also be used
 to populate the ''Component:'' field for tickets.

 The list of those pages could be attached in some ways to
 the developer:
  1. by relationships created between the developer pages
    and the component pages?
  2. by use of the settings?
  3. by a multiselection filter on the timeline?

 The first solution would create some interesting "intelligence"
 about the software infrastructure (i.e. one can image queries like
 ''who works on what?'') but is maybe less flexible than 3.
 Maybe the ideal solution would be 1. + 3., the default selection for 3.
 would be given by 1. ?

-- 
Ticket URL: <http://projects.edgewall.com/trac/ticket/586>
The Trac Project <>


More information about the Trac-Tickets mailing list