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.

---

Note: this ticket was closed in favor of the #11025. No point in modifying this one further.

[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 :(

[Christopher Lenz]

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

[Christopher Lenz]

See also #290.

[Christopher Lenz]

#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

[Christian Boos]

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.

[Christopher Lenz]

#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.

[Christian Boos]

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.

[Christopher Lenz]

​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.

[Christopher Lenz]

See also #3525.

[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 ¾ 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.

[Christian Boos]

(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.

[Christian Boos]

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!

[Christian Boos]

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

[leandor@…]

+1 on this feature request also (and adding myself to the CC list :))

[leho@…]

following

[anonymous]

+1 on this feature request

[anonymous]

+1, please.

[tristan@…]

Added myself to cc. Would very mcuh like to see these plans come to fruition. As it is, we are considering moving to FogBugz due to us needing this ability.

[anonymous]

RedMine has multiproject support built in so may be worth consideration.

[luizcarlos@…]

I have tried the suggestion of Redmine and I moved all projects of my company to it. This process was very very simple because Redmine automatically imported everything from Trac.

I am very really satisfied with Redmine! I think everyone should try it.

[chrisanderson85@…]

Hey guys. Once again: thanks for making a great product. It really has improved all areas of our (modest) development process, but we also require multiple project support as our number of products/components/tickets grows.

Are there plans for an 'official' solution to this or am I another dead-horse flogger?!

Thanks again

Chris

[anonymous]

Chris,

I had the same problem as everybody in this ticket and, since I joined, no further news was sent.

Then, I gave up and tried (experimentally first) the Redmine (www.redmine.org), suggested by someone else in this topic. Redmine imported everything from Trac automatically and does everything Trac do. Now I am using it!

I think everybody should try it.

ps.: look at this: this ticket have 5 years!!!

[chrisanderson85@…]

Cheers anonymous, done and done.

I was reluctant to migrate but unfortunately we need this functionality asap.

Thanks

Chris

[cce@…]

It seems that this issue isn't going to be solved. We're moving off trac at this point, and looking for other options. Roundup seems like a good python tracker, but lacks subversion and the like (it was adopted by Python). The other python related option seems to be drproject, which is now using SQLAlchemy, Dojo, and Markdown.

It's really too bad that Trac doesn't have this critical requirement.

[anonymous]

Replying to cce@…:

It seems that this issue isn't going to be solved. We're moving off trac at this point, and looking for other options. Roundup seems like a good python tracker, but lacks subversion and the like (it was adopted by Python). The other python related option seems to be drproject, which is now using SQLAlchemy, Dojo, and Markdown.

It's really too bad that Trac doesn't have this critical requirement.

We were unable to find other python alternatives too. For us, it was just no longer an option to use Trac without this issue at least seeming to go somewhere. 5 years and still no progress? No more Trac for us, we have also just moved everything to Redmine like several others, despite being a ruby-on-rails platform…

[anonymous]

The first step I would suggest towards multiple project support is a rather innocuous one: to let new projects be created/edited from a web-based administration panel. This would be very useful by itself, and wouldn't compromise any future, more elaborate, multi-project support.

Furthermore, i guess it would be more difficult to people to say that trac doesn't have multi-project support, on a "bullet-points perspective", and probably make those that are asking this feature to be more concrete on what they mean by "multi-project support".

Do you think there might be any chance of this more simplistic approach to make it into trac before 1.0?

[LC]

What does Trac have that makes it so special? What's the reason to wait for something that was opened 5 years ago!

I'm using Redmine since I noticed that this feature wasn't implemented (I will not be in the next recent future) and I'm very satisfied with it.

The best choice I could have done!

[fcorreia@…]

@LC check this thread on the subject: ​http://groups.google.com/group/trac-dev/browse_frm/thread/288b743d1433ae87?tvc=1

[anonymous]

www.redmine.org looks like trac, smells like trac, but has support for multi-project setups. instead of waiting for this bug to be fixed, i too switched to redmine, it works really great!

[anonymous]

We just decided to switch to Redmine for all new projects. The only thing that prevented us before is that you can have the same user database for both svn and trac, while Redmine requires separate databases. But now, as the number of projects our employees are involved with increases Trac is just too cumbersome to maintain, not to mention the complaints about having to check so many websites to see the list of tasks. Not only do we need multiple projects support for Trac, but we need sub projects as well. We also need #31 implmeneted asap if we are to return to Trac.

[anonymous]

there's really no excuse for this ticket to still remain unaddressed. I realize the Trac team doesn't want to 'force' anyone into a certain methodology (see: google groups link above), but give us *something* in the core for multiple projects, and we'll give you feedback and go from there. Redmine might not be all the way there yet as far as a complete Trac replacement, but it's not going to be long before it surpasses Trac in features & functionality. Why let Trac play second fiddle just because no one wants to tackle this issue?

[Christian Boos]

Well, yeah, RedMine is getting pretty good ;-) We're definitely not trying to prevent anyone to switch to Redmine (how could we anyway?).

Long time Trac supporters might be comforted (or not…) by knowing that I still plan to add multiple project support to Trac, one of these days. Let's start by resurrecting a draft proposal I wrote one year ago (TracDev/Proposals/MultipleProject).

This document can be used as a starting point to refine the approach and list the various issues that have to be addressed.

I also change the milestone to experimental, as this topic is not really tied to 1.0. Once there's an experimental branch (source:sandbox/multiproject) for this feature, it'll certainly get a milestone of its own.

[Emmanuel Blot]

Replying to cboos:

Well, yeah, RedMine is getting pretty good ;-) We're definitely not trying to prevent anyone to switch to Redmine (how could we anyway?).

This issue is starting to be a show-stopper for me as well. I would have had to switch to RedMine too if Bitten and other really useful plugin were available for RedMine. It's starting to be very difficult to handle our software development the mono-project way…

I do not blame anyone, it is probably one of the major changes for Trac and is likely to require a lot of work. I now think it's a critical missing feature in Trac, with no usable workaround. Spawning multiple Trac projects is not a solution either.

I'd vote to put this issue as critical for the next major release (0.13). I wish I had some spare time to work on this topic ;-(

[Christian Boos]

Manu, even if you don't have much time to contribute on coding, I'd really appreciate if you could contribute for the requirements and share your vision about how Trac should help support your particular workflow (even in the form of private mails if it's quicker for you that way).

[Emmanuel Blot]

Replying to cboos:

Manu, even if you don't have much time to contribute on coding, I'd really appreciate if you could contribute for the requirements and share your vision about how Trac should help support your particular workflow (even in the form of private mails if it's quicker for you that way).

Sure, I'll try to have a look at the TracDev/Proposals/MultipleProject document.

[fantom@…]

I am very interested in addition of multiple projects support in trac. Probably, I could help with a code writing if I could understand trac kernel. How I have understood you are going to make new experimental branch in svn?

[Christian Boos]

Replying to fantom@…:

I am very interested in addition of multiple projects support in trac. Probably, I could help with a code writing if I could understand trac kernel.

Please check HowToContribute. It is generally considered a good thing to start contributing to small tasks in order to get a grasp of the development workflow and of the inner workings of a project, before tackling on a bigger project, like this one.

How I have understood you are going to make new experimental branch in svn?

When I have some code to share, yes. But please, let's use the TracDev/Proposals/MultipleProject page as a scratch area for further discussion, in order to improve the signal/noise ratio of this ticket ;-)

[ebray]

Yes, well, the other problem with this is that there are those of us who have already implemented our own multi-project systems that we're comfortable with, and don't want them to break by having some new implementation imposed on us.

In my case it's our own damn fault for not open-sourcing, but that's outside of my control unfortunately. But there are other open source projects out there that *have* implemented such solutions.

[Remy Blank]

Replying to eblot:

I'd vote to put this issue as critical for the next major release (0.13). I wish I had some spare time to work on this topic ;-(

I agree with that. Personally, I don't have a use for multi-project (yet), but I do have some time to spend on Trac development. So I guess it will be critically important to have a clear specification before starting on the coding phase.

Still, before starting on 0.13, we have to get 0.12 out of the door, hopefully with multirepos. But that's a subject for another ticket, I guess.

Replying to ebray:

Yes, well, the other problem with this is that there are those of us who have already implemented our own multi-project systems that we're comfortable with, and don't want them to break by having some new implementation imposed on us.

It would still be extremely useful if you could describe the requirements that formed the basis of your implementation, if you can.

[Christian Boos]

Replying to ebray:

Yes, well, the other problem with this is that there are those of us who have already implemented our own multi-project systems that we're comfortable with, and don't want them to break by having some new implementation imposed on us.

In addition to what Rémi already asked you, I'd ask why and how you think your existing multi-project system would break. The planned design is supposed to be fully transparent if only a single project is used (everything belongs to the toplevel project), so I figure existing multi-project setup should continue to work unchanged?

[ebray]

Replying to cboos:

In addition to what Rémi already asked you, I'd ask why and how you think your existing multi-project system would break. The planned design is supposed to be fully transparent if only a single project is used (everything belongs to the toplevel project), so I figure existing multi-project setup should continue to work unchanged?

Good points, both of you. I'll have to think about that and get back to you. I guess it's not entirely clear to me even what "multi-project support" means in this context. When I hear it I think of something sort of along the lines of TracForge. At any rate, as long as it's a relatively minimal support structure I'm sure it shouldn't cause too much harm. I just don't know what that would consist of. I've never found there to be anything terribly missing in Trac to prevent me from doing what I've wanted to do.

[fantom@…]

I want to understand what is already done for resolve this question, and what we should to develop.

[tag]

It's too bad Tram has gone by the wayside. I'm actually looking at moving to redmine because this quickly has gotten out of hand for me (I have multiple interrelated projects which are not all components of the same projects and worse, I have had multiple team structures for them where not everyone really deserves to have access to everything). I'm stopped though, because there are so many outstanding plugins for track I don't know what to do without (like the wysiwyg plugin that actually generates decent wiki markup).

The main thing(s) I'd like to see is the ability to assign and reference bugs across projects. I love the low ceremony part of trac but really need to be able to keep a handle on this the fact that a bug for one of my clients projects that I have 3 subcontractors working on is actually a bug in an internally developed library we're using in that project and have a full time employee working on. Granted, not all business models are as complicated as mine, but still. :-)

[handyande]

Hi all, sorry that !TraM has not been maintained for the latest Trac versions - it became too difficult to maintain cross-version builds due to the fact it was not possible to use the published plugin framework for what it aimed to achieve.

For anyone interested in a completely different look on project management the HeadsUp! (​http://headsupdevelopment.com/) team have just opened a public beta for their solution (​http://headsupdevelopment.com/headsup/testing/). It is aimed primarily at the Maven (Java) community (with build and repository management) but also supports generic projects ala trac.

It may not have all the complexities of per project authentication or cross-project wiki links yet but with appropriate feedback it could all be there for a first release.

[me@…]

To make things easier, why can't we just make multiple projects feature with a SINGLE repo? This would really nicely fit into TracDev/Proposals/MultipleProject model. It would also solve the problem of Changeset numbering and other TracLinks issues mentioned by daniel in the first reply.

Who needs multiple repos for multiple projects anyways? perhaps 1 out of 20 teams? One svn repo for multiple project is a beautiful solution, easier to program, and manage. One access control file (db), no problems with TracLinks. Ofcourse this solution may not fit all developers, but Trac had always had a character, I, personally, don't see a problem with that.

Yes, there are limitations, like porting from existing tracs (ticket numbering, and versions will not fit) but otherwise who cares its a more logical solution in my opinion.

[Daniel Serodio <dserodio@…>]

Replying to me@…:

To make things easier, why can't we just make multiple projects feature with a SINGLE repo? This would really nicely fit into TracDev/Proposals/MultipleProject model. It would also solve the problem of Changeset numbering and other TracLinks issues mentioned by daniel in the first reply.

I agree, multiple projects for a single repo would solve the majority of use cases and is a viable target.

[olemarkus.with@…]

Multiple repos is a requirement for us. We use Git and having multiple projects in the same repos is not very feasible with Git. Git has drastically increased its userbase lately, so to focus on SVN only is short-sighted.

If this is ever going to be done, it should be done properly.

[Daniel Serodio <dserodio@…>]

Replying to olemarkus.with@…:

Multiple repos is a requirement for us. We use Git and having multiple projects in the same repos is not very feasible with Git. Git has drastically increased its userbase lately, so to focus on SVN only is short-sighted.

If this is ever going to be done, it should be done properly.

This "all or never" approach has prevented this feature from being implemented over the last 6 years. We need a "good-enough" (some compromises needed) initial implementation.

[Daniel Serodio <dserodio@…>]

Replying to Daniel Serodio <dserodio@…>:

Replying to olemarkus.with@…:

Multiple repos is a requirement for us. We use Git and having multiple projects in the same repos is not very feasible with Git. Git has drastically increased its userbase lately, so to focus on SVN only is short-sighted.

If this is ever going to be done, it should be done properly.

This "all or never" approach has prevented this feature from being implemented over the last 6 years. We need a "good-enough" (some compromises needed) initial implementation.

Sorry, I meant "all-or-nothing"

[olemarkus.with@…]

Well. True that some is better than nothing, but when Redmine already have 'everything' in this case, we won't make the switch back to Trac. I'd rather wait one more year for something proper than 6 months on something we cannot use.

[raphael.carrier@…]

Cluemapper has a dashboard components and automates the creation of new trac instances and svn repos

​http://projects.serverzen.com/pm/p/cluemapper

[Christian Boos]

Note that the point of this ticket is to achieve something better than a simple aggregation of multiple Trac instances.

ClueMapper does look like a nice integration project with lots of added value, but AFAICT, there's no concept of merged timeline or roadmap, nor overall search and query capabilities, etc.

MultiProject will likely be one of the big topics of 0.13 (see comment:117 and follow-ups).

[keith@…]

I think the solution is twofold.

1. Multiple project support in single repo. This solves the issues with TracLinks and ticket numbering etc. It would also cover most use cases for companies like the one I work for e.g. using Trac to track bugs for websites. Components *work*, but when you have a lot of them it becomes clumbsy and difficult to separate them out. Lots of manual work involved.

2. Simplify the creation of Trac repositories. My absolute biggest complaint with Trac is just how much of a pain it is to set up a new repository instance. Multiple projects just wouldn't be an issue if I could simply create a new Trac repository without SSHing into our server and editing config files. It would be great to be able to simply create a new Trac repository from the web that works off a subfolder of our SVN repository or a different repository.

We've been cramming stuff into one trac repo and hacking milestones, components, versions and ticket types for a long time to get around it.

[trivoallan@…]

Replying to keith@…:

We've been cramming stuff into one trac repo and hacking milestones, components, versions and ticket types for a long time to get around it.

My company developed a piece of software to solve this issue : ​http://www.clever-age.org/trac/wiki/cleverbox

The website is not quite up to date, but the solution is still actively maintained and developed.

HTH

[jason.heeris@…]

I just wanted to add my 0.05(*) and support what Daniel Serodio said. Unlike a lot of other commentators here, I don't particularly need huge inter-project integration or cross-linking. My situation is that we'd like to track bugs in various unrelated projects, but I don't want to have to:

• Add a new Trac environment
• Manually duplicate all users
• Manually update the Apache conf
• Manually duplicate all configuration, custom fields, changes to priority labels, bug classes, templates, etc

…for all of the projects, and again every time we add a new one.

In our case, the projects are completely unrelated, I just need a way to make sure bugs in SoftwareA remain separate from FirmwareB, while sharing users, config, etc. I know it's not what everyone else seems to be asking for, but there are users with a use-case in that middle ground.

[olemis+trac@…]

My $0.02 … after reviewing the wiki page I wanted to make a single question :

• What about turning (projects | sub-projects) into resources as well (instead of adding the separate project parameter) ?

I think that it would be nice to lookup & retrieve resources uniformly (to make it look something like the Unix FS, where everything is possible and the world starts at the top, and not like the Windows FS, where many things are difficult to achieve and there's an infinite amount of scattered & unrelated villages :-$ ), and that could probably be achieved if (projects | sub-projects) are considered as resources as well

BTW : Cool feature !

[nhpatt@…]

+1, please.

[Christian Boos]

Replying to Daniel Serodio <dserodio@…>:

Replying to olemarkus.with@…:

Multiple repos is a requirement for us. We use Git and having multiple projects in the same repos is not very feasible with Git. Git has drastically increased its userbase lately, so to focus on SVN only is short-sighted.

If this is ever going to be done, it should be done properly.

This "all or never" approach has prevented this feature from being implemented over the last 6 years. We need a "good-enough" (some compromises needed) initial implementation.

Well, the MultipleRepositorySupport prerequisite is not a blocker anymore: we have it now in 0.12 and it's an important building stone for a good and flexible MultipleProjectSupport:

• some setups will have all their projects related to one repository; no need to take the MultipleRepositorySupport into account, they'll just work with the default repository
• some setups will have one repository for each project: that's a very simple mapping, inside resources belonging to that project, TracLinks will refer to that repository, as if it would be the default repository (this will work thanks to the WikiContext, another prerequisite which is now something granted)
• other setups will need a more complex mapping; typically the few tools, libraries, or other 3rd party repositories that are shared across various projects dedicated to product or product families. In this model, each project can be associated to multiple repositories, one of them can be defined as the default one for the project; a given repository can be associated to several projects.

The latter is the typical "enterprise" setup which I'm targeting. Because it's also the more general model, it can easily accommodate the two previous simpler cases.

So I agree with both of the opinions stated above: now that we have most of the prerequisites in place, let's seriously start to get the ball rolling, with something good enough (but nevertheless aim for something great ;-) ).

When I say most of the prerequisites, I specifically see the GenericTrac one as the last missing piece, as I believe only this will give us the necessary flexibility to handle the complex relationships we'll need for good multiple project support. The nice part is that at this point we won't even need a db schema migration to add multiple project support, as both the projects themselves and the relations from other resources to the projects will be stored in the standard model (and this should also answer comment:143).

[Christian Boos]

Replying to jason.heeris@…:

… I don't particularly need huge inter-project integration or cross-linking. My situation is that we'd like to track bugs in various unrelated projects, … I just need a way to make sure bugs in SoftwareA remain separate from FirmwareB, while sharing users, config, etc. I know it's not what everyone else seems to be asking for, but there are users with a use-case in that middle ground.

This requirement is interesting, as there are actually two "flavors" of it.

One is the use case discussed in TracDev/Proposals/MultipleProject#ProjectTree, the Several independent projects setup.

In that case the project "tree" is one level deep, there's a "global" project and a series of unrelated children projects.

While the use of this global project will probably have to be restricted in a setup like this, e.g. so that you can't create a ticket attached to that project, it should still be useful to switch to a global view, like when you want to have an overview of the activity in all project in the global timeline, or have a view over all the tickets an user is involved with in his user page, etc.

The other possibility is to really have a set of unrelated toplevel projects (i.e. a forest). There wouldn't be a global project to conveniently pick a level where one would get a "global" overview, but on the other hand, for getting a similar kind of overview, it should still be possible to explicitly select several projects.

So there shouldn't be much differences between the two flavors if there's nothing to share from a global project (like, no common components). But admittedly, defining precisely how the sharing will work in the different situations is still something that has to be clarified in the design (we need to find something at the same time intuitive, flexible and fast).

[garyo@…]

Replying to cboos:

So I agree with both of the opinions stated above: now that we have most of the prerequisites in place, let's seriously start to get the ball rolling, with something good enough (but nevertheless aim for something great ;-) ).

This is HUGE news! We are just about to investigate switching to redmine for this one feature (but would rather not — we love Trac). We're just getting too big and need multiple projects that are related but independent. If Trac is going to get multi-project support, anything even close to TracMultipleProjects/SingleEnvironment or TracMultipleProjects/ByProductAndSearch#TracData, then we will eagerly pretest it, and can probably spare a little dev time to help design/implement/bugfix.

[Christian Boos]

Replying to garyo@…:

… you could have project "A" with milestone "v1.0" and project "B" with milestone "v1.0" but they are distinct milestones.

That would be one scenario. But we also need to support the other way round: if you have project "A" and "B" corresponding to products part of a same product family, which are going to be shipped together, it would be useful to have milestone "v1.0" be the same for both "A" and "B".

You could therefore want to look at this milestone in the scope of either "A", "B" or want to have an overview of "v1.0", for all relevant sub-projects.

[andrew@…]

Replying to cboos:

That would be one scenario. But we also need to support the other way round: if you have project "A" and "B" corresponding to products part of a same product family, which are going to be shipped together, it would be useful to have milestone "v1.0" be the same for both "A" and "B".

This is a particularly complex requirement as I understand it. The way that HeadsUp Agile (free beta download ​http://headsupdev.com/agile/signup/) tackles this is using project hierarchies. You can define a milestone in a parent project and then assign issues from children to this milestone. In the dashboard visualisations all "next" milestones including children can be aggregated to show overall how close you are to the next goal (or you could see the project graphs individually).

Yes the hierarchy is based on Maven POMs but we are looking to work on other formats so any feedback would be welcome - see the product so far at ​http://headsupdev.com/

[James Owen <james.owen@…>]

What's the status/plan on this multi-project feature?

In a similar situaiton to above

• must have multiple project support
• must have tiered security
• users can only see projects (and related reports/tickets/features/milestones/etc they are enabled to see with permission

[Christian Boos]

Replying to James Owen <james.owen@…>:

What's the status/plan on this multi-project feature?

We gather the requirements and think about the model.

In a similar situaiton to above

• must have multiple project support
• must have tiered security
• users can only see projects (and related reports/tickets/features/milestones/etc they are enabled to see with permission

Thanks for providing some requirements! Feel free to add to the TracDev/Proposals/MultipleProject wiki page, either by commenting what's already there in line, or adding new sections (like Use Cases, Discussion etc.)

[james.owen@…]

thanks for the update, is there a timeline in mind (ticket shows 0.13 release) due in 4 months (end of this year)?

I will look at the wiki and update with my items.

[mjklaim@…]

Hi, I just wanted to ask if this feature will allow having specific ticket-workflow by project or project group? Maybe by giving names to ticket-workflows and allowing to connect a project to a workflow?

[Christian Boos]

Replying to mjklaim@…:

Hi, I just wanted to ask if this feature will allow having specific ticket-workflow by project or project group? Maybe by giving names to ticket-workflows and allowing to connect a project to a workflow?

We would basically have the same problematic than with per-type workflow (see #6548), i.e. what happens to the status when a ticket gets moved from one project to the other? The simplest solution would be to reset it to the new status.

In order to easily define multiple workflows, one could think of having per-project sections in the TracIni file (e.g. [ticket-workflow.proj]). That would also ease the process of project consolidation (integrating an existing single project instance into a multiple project instance).

In a similar way, #7508 (a duplicate of this one) asked for per-project components. Components are not defined in the TracIni file, but things like default_component is, or custom fields… So we might adopt the same approach for the [ticket] and [ticket-custom] sections.

[mjklaim@…]

Replying to cboos:

We would basically have the same problematic than with per-type workflow (see #6548), i.e. what happens to the status when a ticket gets moved from one project to the other? The simplest solution would be to reset it to the new status.

Certainly the simplest solution. Someone with rights would then move the ticket to the right state I guess.

In order to easily define multiple workflows, one could think of having per-project sections in the TracIni file (e.g. [ticket-workflow.proj]). That would also ease the process of project consolidation (integrating an existing single project instance into a multiple project instance).

I really think it's not a good way to manage it because in an environnement where you would have multiple projects, it's very possible that several projects have the same ticket workflow, with just exception in some projects.

So I think decoupling projects from ticket-workflow would help avoid having to maintain multiple same workflow definition in each project .ini file. A project should "use" a workflow for it's tickets, not "be" a workflow.

In a similar way, #7508 (a duplicate of this one) asked for per-project components. Components are not defined in the TracIni file, but things like default_component is, or custom fields… So we might adopt the same approach for the [ticket] and [ticket-custom] sections.

I agree that components should be project-specific. That's for the same reasons I think ticket-workflow shouldn't be project-specific. (is there already a ticket about that? I can add one if you think it's a valid suggestion)

[Christian Boos]

Replying to mjklaim@…:

(is there already a ticket about that? I can add one if you think it's a valid suggestion)

I'd prefer that for now we continue the design discussion in the TracDev/Proposals/MultipleProject#Workflow section.

[Christian Boos]

(the other address of primski@…)

[anonymous]

I'm not sure if this is the correct place, but my organization is just now moving to the trac tool for change and defect management. Our current tool has the ability to set a standard or even customized workflow by ticket type (ie. defects have a standard workflow, tasks have a workflow and we could set the ticket types needed per project) I was surprised that there wasn't that capability here yet. It is definately useful.

[jay@…]

remove

[anonymous]

Just a note to folk still monitoring this issue looking for real multi project support:

HeadsUp Agile (running at ​http://headsupdev.org/) is now an open source project which you can grab from ​http://github.com/headsupdev/agile/. The Agile project is built on multi project from the ground up so there are no compromises to run all your projects and you also get great aggregation if issues, milestones, activity etc!

If there is lots of interest on this topic I am sure that a Trac importer could be written to aid in the evaluation.

[fbrettschneider@…]

Note that there is currently something going on with implementing TracMultipleProjects/SingleEnvironment by plugin ​TH:wiki:SimpleMultiProjectPlugin…

[lkraav <leho@…>]

Nokia seems to have just a few days ago open sourced their own ​MultiProject plugin for running ​https://projects.developer.nokia.com + several other plugins they've had to patch for this. Those are also listed on MultiProject page - BatchModify, ChildTickets, TracDownloads, TracDiscussion. Since this work is done by a big commercial entity and Nokia Developer Projects website looks awesome, this is bound to have some great stuff. Let's dig in and share some findings here!

[adrian.price@…]

Replying to anonymous:

Just a note to folk still monitoring this issue looking for real multi project support:

Advertising your competing project in a ticket comment is not only spam, but in poor taste.

[anonymous]

How is it different to the redmine comments?

[aaron@…]

Replying to adrian.price@…:

Replying to anonymous:

Just a note to folk still monitoring this issue looking for real multi project support:

Advertising your competing project in a ticket comment is not only spam, but in poor taste.

It's hardly spam when it's clearly intended to help people fill a need that Trac cannot.

[franz.mayer@…]

Replying to fbrettschneider@…:

Note that there is currently something going on with implementing TracMultipleProjects/SingleEnvironment by plugin ​TH:wiki:SimpleMultiProjectPlugin…

The Plugin looks promising (from screenshots) - I will try it when I've time.

Two questions about that:

• why is the plugin not mentioned in Wiki page TracMultipleProjects/SingleEnvironment?
• would the plugin be a good starting point to integrate the requested feature into Trac? (as it has been done with ​Git plugin, see #10594)

[fbrettschneider@…]

Replying to franz.mayer@…:

• why is the plugin not mentioned in Wiki page TracMultipleProjects/SingleEnvironment?

I've added a note under 'plugin solution'.

• would the plugin be a good starting point to integrate the requested feature into Trac? (as it has been done with ​Git plugin, see #10594)

The main technical difference would be to extend the Trac core with a new standard ticket field 'project' and to work in the standard db tables, in spite of the plugin that uses a custom ticket field 'project' and adds new tables for mapping the project to other ressources. Furthermore, we're not the smartest Trac developers, so the code may need some reviewing… ;)

[lkraav <leho@…>]

Nokia has been actively maintaining their multiproject Trac solution I mentioned in comment:179. Has anyone here found time to take it for a spin + perhaps take it apart and see what's under the hood?

[anonymous]

It's funny for me to still get email notifications on this ticket that I commented on SEVEN YEARS AGO. Would someone on the project please mark it as "won't fix" and close this ticket, and disable any further comments? I mean, come on :)

[lkraav <leho@…>]

Replying to anonymous:

It's funny for me to still get email notifications on this ticket that I commented on SEVEN YEARS AGO. Would someone on the project please mark it as "won't fix" and close this ticket, and disable any further comments? I mean, come on :)

Better solution would be to remove yourself from the CC list in Modify Ticket panel. Enter your e-mail address in Preferences, first.

[Christian Boos]

Well, I admit he does have a point. While we haven't given up all hopes to implement real multiproject support one day, most of the people subscribed here did so long time ago and have most likely switched to alternative solutions since.

So we can indeed close this one as "duplicate", and start anew. Funny enough, the description of this ticket while extremely short still mostly captures what I'd like to see as multiproject support…

So I just created #11025 to that effect.

If anyone felt like modifying or commenting further on the present ticket, please use #11025 instead.