Multi-project support

[anonymous]

Support multiple projects with different sets of components, version numbers, and milestones in the ticketing system, and different repositories in the browser.

This is different from TracMultipleProjects because to provide e.g. a merged Timeline and Roadmap, the different projects would need to be in the same database.

[daniel]

The short answer: no.

The "Trac" way to accomplish this is to create multiple trac databases corresponding to each repository.

This is because, the way Trac explicitly refers to changets, files and subversion commits... If you had more than one repository, the TracLinks would become ambiguous...

Example: Changeset [42] .... Trac can't know which repository changeset 42 refers to.

[anonymous]

I'm also interested on using trac with multiple repositories on the same server, is there any way to create multiple databases as you say and that trac.cgi can select one or another with a parameter?

[anonymous]

I figured out how to make it work ... setup as databases as repositories you want to have, then symlink trac.cgi as many times as repositories with different names (trac-repos1.cgi, trac-repos2.cgi, ...) then edit apache configuration and set different TRAC_DB variables to each repository using each symlink name and that's it ... an example of apache conf:

# repository 1 <Location "/cgi-bin/trac-repos1.cgi">

SetEnv TRAC_DB "/home/svn/trac/repos1.db"

</Location>

<Location "/cgi-bin/trac-repos1.cgi/login">

AuthType? Basic AuthName? "repos1" AuthUserFile? /home/svn/users/repos1 Require valid-user

</Location>

# repository2 <Location "/cgi-bin/trac-repos2.cgi">

SetEnv TRAC_DB "/home/svn/trac/repos2.db"

</Location>

<Location "/cgi-bin/trac-repos2.cgi/login">

AuthType? Basic AuthName? "repos2" AuthUserFile? /home/svn/users/repos2 Require valid-user

</Location>

[Nathan Miller <nxmiller@…>]

I agree cnanging TracLinks syntax has some disadvantages

but why do not I have ONE common timeline for all my projects ?
or common "New Ticket" form, common Roadmap ?

it is not good to see into about 10 timelines :(

[cmlenz]

• Changed summary and description to better reflect the request.
• #272 marked as duplicate.

[cmlenz]

See also #290.

[cmlenz]

#1048 has been marked as duplicate of this ticket. See that ticket for a nice description of the requirements for multi-project support.

[Brad Anderson <brad@…>]

A potential data model change could help this. It's located here. We could add a field for project_id, but have the Milestone module not take that field into account. And for single project instances, this new field is always 1. Hides complexity for those who don't require it.

[garyo]

Hi, I'm a new potential user of trac. It looks beautiful, but the lack of subprojects is a showstopper for us.

In our situation, we produce multiple products from the same source repository (we write plug-ins and they plug into various host products). Each product/subproject has its own version numbering, components, and milestones but our whole world is in a single svn repo. So for us the repository ambiguity referred to above would not be an issue. We would be happy just to have a 'project' table and have the other tables refer to it, and have the reports adjusted appropriately.

Multiple separate tracs are not good for us, since tickets may refer to the whole system (not just a single project), and we'd like to be able to move a ticket from one subproject to another easily (e.g. by just changing its project id), and we definitely need a merged timeline and roadmap (what's coming up soon?)

This limited change seems pretty simple. Would enough people be interested in it to make it worthwhile?

-- Gary O

[cboos]

Hrm, I made a lot of noise today at #586, with ideas that would have been better expressed here... Gary, can you have a look there and tell me what you think?

[Stephen Kestle <d@…>]

This feature should be able to assign tickets to multiple projects. One common operation that we do is unifying utility code from a number of projects into a common tools project. It would be wonderful to be able to record this for what it is.

This should eventually mean that each project on the ticket would need it's own status and resolution fields (presumably the code moving would be done over a number of check ins), but this would not be immediately necessary (of course).

[ben@…]

I'll echo my support for this. Having to separate code libraries that reference a shared code base is a DRY nightmare waiting to happen.

[cmlenz]

#2262 has been marked as duplicate of this ticket.

[eoin.dunne@…]

I entered the issue 2262, so I thought I would just add my two cents worth here. One of the main issues in my mind is simply reporting. Trac doesn't have a concept of a product because it is assumed that one Trac-Instance=one product.

This doesn’t help at all though if you are building many products off of a common framework. We wrote a small little python script that closes tickets automatically when the bugFix capability of Tortoise is used (the bug link). We parse out the ticket number from the log and then close the ticket in trac. But if an issue is actually a bug in the dependent framework not in the top level project, then we have to manually remember to find that ticket and close it. If Trac had the concept of a product built into it then it would allow the flexibility to manage larger projects.

In it’s current form Trac is not an enterprise solution that can be used on a suite of products developed off a common framework.

Trac is a great tool that I think is being held back by something that could be fixed quickly. Just add a new table called product to the db. Any tickets that are created simply need to have a product field added to them. That’s it! This would allow dev teams the flexibility of using trac to either manage small projects where these larger project dependencies don’t exist, and it would let Trac be usable in more midsize projects.

I'm bumping the priority on this because it is an old issue that doesn't seem to be getting the attention that it needs despite the many duplicate bugs that have been logged against this very issue. I wish I could change what milestone and version this should be addressed at as well but I'll leave that to the powers that be.

[masonjm@…]

I just created TracMultipleProjects/MultipleEnvironmentsSingleDatabase

It's not a "solution" exactly, but it might be a workaround for some people until this ticket is resolved.

[dserodio@…]

(Should I add this comment here, or under TracMultipleProjects/MultipleEnvironmentsSingleDatabase ?)

Why db_user instead of project_id ?

[masonjm@…]

Well, the only way I could think of to distinguish different trac instances is through the user used to connect to the database, hence: db_user. I suppose the views could use a lookup table that mapped db_users to project ids. That would require more work to setup a new project, but probably not a big deal.

[Russell Hind <rhind@…>]

We also have multiple projects but in the same subversion repository becaus they share much common code. We would like per project components, versions and milestones. If this means we only get a timeline per project then that is ok with us but at somepoint it would be nice to see an overall timeline for all projects but not essential.

Thanks

Russell

[pacopablo@…]

I took a slightly different approach to the multiple projects in a single database. My approach was to leverage schema support in PostgreSQL. I realize that it excludes users of SQLite or any other future database, but it seemed the path of least resistance.

Details of my patch are available at http://embassy.asylumware.com/projects/trac/wiki/Patches/Schema

[liam@…]

Am very interested in Trac (good to see Strict conformance in particular), but am disturbed by this lack of support for different projects with unified timelines/codebases.

I also work for a very large company that manufacture credit card terminals, it would be great to pitch this product to my boss but all our terminals work off - more or less - a unified code base. We would also need to see unified timelines for subprojects.

Will be watching for when this ticket is resolved (without dirty hacks!)

[husted@…]

Has anyone suggested a standalone "enterprise timeline" product that could examine a number of Trac projects to generate an overall status report?

Rather than change Trac, perhaps we could add a "dashboard" product that could monitor multiple Trac projects, maybe even in different locations.

This might even be something a person could run locally, to "track" seemingly unrelated projects. A "MyTrac?", so to speak

-Ted.

[cboos]

Replying to husted@apache.org:

... Rather than change Trac, perhaps we could add a "dashboard" product that could monitor multiple Trac projects, maybe even in different locations.

Though I don't know yet the details, the TracHacks:TracForgePlugin seems to undertake a similar approach.

[anonymous]

In my company the reason we are reluctantly dropping Trac is that it is impossible to generate reports showing tickets from multiple projects. For example, a view showing My Tickets across all projects organized by milestone-due-date or priority doesn't seem like an exotic, unreasonable or even uncommon thing to want. We have no need for a cross-project wiki, timeline, browser or roadmap, although others might. We need separate roadmaps for each project, so we can't use components.

This is miscategorized as an enhancement - it is a design defect, and fixing it would be the #1 way to make Trac a more useful (and used) piece of software. It is not helpful to say that the Trac way of doing this is, in effect, to keep several browser windows open and look at all your tickets from different projects on different pages, sorting all the priorities and due dates in your head. We've tried that and found that it really sucks, and we are not alone. Please consider making this a top priority, decreasing the target milestone number, and changing its type to "defect".

[anonymous]

Replying to anonymous:

In my company the reason we are reluctantly dropping Trac is that it is impossible to generate reports showing tickets from multiple projects.

In my company we had the same view. We have multiple projects that need to be accessible within a single framework for issue tracking because in many ways issues are inter-related. We looked into Trac and found it really lacking. In my opinion this is a defect and not a feature. We have gone with FogBugz? instead.

[cmlenz]

How to manipulate me

An enhancement is an enhancement, period. And this one is a really large one. We never claimed that Trac was particularly fit at managing multiple projects.

[andy@…]

I have been working on a Trac Multi wrapper ("TraM") which helps me to see what is goign on with my multiple projects. The performance is not as good as trac, as it does currently open all project databases for many of the pages, but I am working on that.

This is only just started, so don't complain too loadly ;) You can see it in action at http://dev.rectang.com/projects or grab it at http://dev.rectang.com/projects/tram

HandyAndE

[anonymous]

At first glance, TraM looks nice, but there is no way to download it! (see http://dev.rectang.com/projects/tram/ticket/1)

[andy@…]

Apologies, updated info at http://dev.rectang.com/projects/tram/wiki/WikiStart. I hope to get it packaged and an install script set up in the next couple of days too.

[cmlenz]

See also #3525.

[catholic_poster@…]

Unified Single View of Multiple Trac Milestones/Tickets - See Tram Project http://dev.rectang.com/

[anonymous]

One of these dashboard-type solutions seems like it would be ok... One thing that might facilitate this sort of thing would be the ability for multiple trac environments to share the same database, maybe using a table prefix for all the tables of each environment. Then you could just do SQL queries across the tables. someone seems to have gotten this semi-working here: http://trac.edgewall.org/wiki/TracMultipleProjects/MultipleEnvironmentsSingleDatabase and http://embassy.asylumware.com/projects/trac/wiki/Patches/Schema

[anonymous]

The point was raised that nobody claimed that Trac was suited for multiple projects. Given that such a change is pretty large, it is understandable why this has not been addressed yet. However, to make the claim that 'we never said we did that' flys in the face of community development.

It seems like a more appropriate and realistic responce is probably:

This is recognized as a defficiency in the product but we don't have the resources to fix this at the current time. If you would like to contribute a patch for review, we will certainly take it into consideration.

[trac@…]

Akismet is annoying

[Gary Wilson <gary.wilson@…>]

I came across DrProject (from a blog entry on Daily Python) today, which seems to have created a multi-project Trac. Some implementation issues are talked about on the blog.

"DrProject is a lightweight software project management portal derived from Trac and specialized for classroom use."

[anonymous]

We're also evaluating trac. It has too much upside to give it up completely, but this issue could be it's fatal flaw for us as well.

[bangcok_dangerus ( at ] hotmail.com]

I'm working for a small (~4 developers) software company. We use one subversion repository for all projects. As great as trac is, implementing ideas in this discussion would make it far more useful to us. Right now we've decided to use multiple trac environments (and hence databases), and specifying the path to each subdirectory in the repository as the environment's "repository". Another option we considered was using the whole repository as one trac environment adding a custom ticket field called "Project", with a manually created list of the projects in the repository (see TracTicketsCustomFields ). However, this makes it harder to easily add and remove projects.

Basically, this is just a another vote in favour of the proposals being discussed :)

[anonymous]

Replying to eoin.dunne@divestco.com:

I entered the issue 2262, so I thought I would just add my two cents worth here. One of the main issues in my mind is simply reporting. Trac doesn't have a concept of a product because it is assumed that one Trac-Instance=one product. This doesn’t help at all though if you are building many products off of a common framework. We wrote a small little python script that closes tickets automatically when the bugFix capability of Tortoise is used (the bug link). We parse out the ticket number from the log and then close the ticket in trac. But if an issue is actually a bug in the dependent framework not in the top level project, then we have to manually remember to find that ticket and close it. If Trac had the concept of a product built into it then it would allow the flexibility to manage larger projects. In it’s current form Trac is not an enterprise solution that can be used on a suite of products developed off a common framework. Trac is a great tool that I think is being held back by something that could be fixed quickly. Just add a new table called product to the db. Any tickets that are created simply need to have a product field added to them. That’s it! This would allow dev teams the flexibility of using trac to either manage small projects where these larger project dependencies don’t exist, and it would let Trac be usable in more midsize projects. I'm bumping the priority on this because it is an old issue that doesn't seem to be getting the attention that it needs despite the many duplicate bugs that have been logged against this very issue. I wish I could change what milestone and version this should be addressed at as well but I'll leave that to the powers that be.

Well it's 2007, I entered my orginal comment here in 2005. I still think the solution is to add a product table. Then modify the ticket table to include a product id column, and just like that Trac supports multiple projects in a single TRAC instance.

Ok, I know it's not that simple as the concept of multiple products/projects is not supported by the rest of TRAC. But it's a manageable solution that should be looked at.

The problem goes beyond having to have multiple browsers open to view multiple projects. Currently I'm managing about 20 seprate TRAC projects. So configuration has to be done seperately for each project, as well as DB migration on upgrades, backups etc.etc. I've had to write some custom python scripts that automates rolling out new versions of the software.

Ok, some people may point out that I got myself into this mess. As they say TRAC never claimed to support multiple projects. The thing is (and I think this is common to other companies as well), is you usually will do a proof of concept with a product on a smaller project. Other people see the job TRAC does managing the single project and say "hey that's cool, can you set my project up like that as well", and before you know if you've got 20 seprate trac instances going.

So this is actually a complement to the guys who work on trac. Maybe you shouldn't have built such a great product, then no one would use it and we wouldn't be having this discussion.

[garyo@…]

+1 from me! I sent this to the mailing list in June of 2005

• a new table, "project", looking like this:

id integer PRIMARY KEY, name text, description text

• make tickets, milestones, and wiki entries (and maybe components?) have a project id, so for instance you could have project "A" with milestone "v1.0" and project "B" with milestone "v1.0" but they are distinct milestones.
• the default project ID, 0, means "no project", i.e. current behavior.
• update various pages and sql queries to allow project selection, i.e. "where project_id = selected_project_id" or sometimes "where project_id = selected_project_id or project_id = 0" to also show the default (non-project-specific) items.
• add a new page for project maintenance (create, update, delete) (Or do it via trac-admin)

This all seems quite limited in scope, and quite doable. See also TracMultipleProjects, and my original mail: http://lists.edgewall.com/archive/trac/2005-May/002932.html.

[anonymous]

Replying to anonymous:

Replying to eoin.dunne@divestco.com:

I entered the issue 2262, so I thought I would just add my two cents worth here.

... Well it's 2007, I entered my orginal comment here in 2005.

Looking at the dates, it's more like 1 year and 2 months ago than 2 full years, though, and a lot of other interesting stuff happened in Trac during that period :)

That being said, it's true that multi-project support is one of the oldest major feature request and certainly deserves consideration. I just wanted to mention that some recent additions to 0.11, namely the WikiContext, will probably make the switch easier. As we make more use of that through the code base, we will possibly have a convenient way to carry the project information by making it another property of the context. This will avoid to have to rewrite 3/4 of the existing API to pass the project information around...

On another front, the GenericTrac proposal is about rationalizing the DB layout used for storing the Trac resources. It might well be another place where adding multi-project support up-front in the design would be interesting.

[cboos]

(forgot to login, but the anonymous above was cboos, as some might have guessed ;) )

[anonymous]

So this is actually a complement to the guys who work on trac. Maybe you shouldn't have built such a great product, then no one would use it and we wouldn't be having this discussion.

Beautifully put. +1

[mala]

Why isnt it possible to get a simple report of all the projects report page. In my company, we would like to be able to log in and see all tickets assigned to me / a specific user. For me, it sounds like simply query all projects entries and merging them together in a single browser window? You are trending to support MySQL. Very good. Should make this possible.

[andy@…]

TraM does support this for trac 0.9.6 (on the correct branch) but it's core is currently being rewritten to support trac 0.10 and most features are currently broken.

HandyAndE

[sam@…]

It's good to see that this will be dealt with in v2.0 - however it's anybody's guess when that will be released ;-)

We have a similar situation to a few people posting to this list: multiple projects that share code, loaded into the same subversion repository. We have worked around this by using different components for the different projects. A few naming conventions and some custom reports, and we have a usable system except for the following limitations:

• Component list can get long.
• The milestone view is quite cluttered.
• We can't allow any client/user access to our repository because we can't limit access by component.

The last point is the most important. What it comes down to, really, is implementing a better permission model: one that gives you a timeline view of *SOME* records.

Adding a product table, and a product column to most tables (component, ticket, milestone, version), would lay the groundwork for a permission model that let you restrict access to specific products: you'd need to add a bunch of "WHERE product in (XXX)" clauses to the queries used to generate the various views.

It would be feasible to leave this duty up to the report designer - you could add a variable such as $PRODUCTLIST, a comma separated list of the products to return.

[mala]

Thanx for the hint refering TraM. I will test it. You said

but it's core is currently being rewritten to support trac 0.10 and most features are currently broken.

The repos has been modified last time two months ago, so it should work with 0.9.6, right?

[andy@…]

If you use the "tram-0.9x" branch then it should be just fine on 0.9.6 - that was my testing version of trac.

[cboos]

Well, I think that there's now enough elements at our disposal for moving a bit this goal closer to reality (1.0 vs. "blue sky" 2.0, though some will object that 1.0 could also be seen as "blue sky" since we opted for the 0.1x release naming scheme ;) ).

I've updated a few design documents in order to detail a concrete plan to add multi-project support to Trac

• TracMultipleProjects/SingleEnvironment#ProposedImplementation
• GenericTrac for the datamodel
• WikiContext for conveying the project information
• PermissionPolicy for handling permissions across projects
• VcRefactoring#SupportforMultipleRepositories

This will probably in turn lead to a TracDev/Proposals/MultipleProject? synthesis at a later point.

[anonymous]

+1 from here too.

We also have several projects on a single svn repository and would love to use trac for this without having to run multiple instances of it (that makes it more difficult to get a good view of the big picture)

[andy@…]

For any of those that were waiting the TraM script (http://dev.rectang.com/projects/tram) now supports Trac 0.10.x - finally!

Currently it supports all the features that TraM for Trac 0.9.x had, but I will be adding more shortly.

Andy

[DarTar]

Another +1 from the Wikka Dev Team.

We are planning to use Trac as an interface to a single SVN repository to maintain user-contributed plugins for WikkaWiki. Each plugin will be hosted as a subproject in a dedicated directory of our SVN repository and ideally have its own milestones, versions and tickets. Real multi-project support is what we need to be able to implement this.

[Robert Hopson]

Adding myself to the CC list

[ThurnerRupert]

wiki:TracMultipleProjects/ComprehensiveSolution seems one of the more promising approaches - even if it probably should be called still tracforge ;)

[garyo@…]

Replying to ThurnerRupert:

wiki:TracMultipleProjects/ComprehensiveSolution seems one of the more promising approaches...

Actually it's not at all for us, and I think most of the posters on this issue. Tracforge is oriented toward a single dashboard for multiple disconnected projects. For us the main issue is about handling a single svn repo which produces a family of related projects, and having a single trac view of all of them, while being able to classify tickets and timeline elements as related to a particular project or projects. Like others, we're currently using components for what should be projects. Just FYI. (Lest you think I'm complaining, trac has been the best thing for our development workflow ever, and we couldn't live without it anymore.)

[commanderTom75@…]

It would be also great if there is one page with summary or statistic information over all projects. That the user can see directly how many tickets are open in project A or is the milestone XY finished in project B.

An implemented search function over all projects would be also nice.

[andy@…]

Heh, my TraM system (http://dev.rectang.com/projects/tram/) provides exactly that kind of summary page, with a cute little graph too. See it in action on http://dev.rectang.com/projects/all/.

Hmm, SpamBayes? keeps rejecting my entry!

[cboos]

Replying to andy@handyande.co.uk:

See it in action on http://dev.rectang.com/projects/all/.

Sadly someone turned off the light there ... :-)

(consider the use of some more contrasted colors please!)

[andy@…]

Ah, that is just the theme for my website - the default styling matches the vibrant trac design. Apologies for the confusion!

[anonymous]

added myself to the cc list