[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