Noah Kantrowitz wrote: > I have also explained many times on this list why we have put off multiple > project support (including subprojects), but just for kicks: > > People are very quick to ask for "multiple project support", citing tools > like GForge or Redmine that can do it so it must be easy. This fails to take > a very important part of the Trac philosophy into mind; we go as far as > humanly possible to not enforce any project management philosophies on the > end user. The fundamental problem with mutli-project support is that if you > ask 10 people what they want from it, you get back 10 different "critical" > feature lists. This leaves us in a quandary. Constructing a single design > that allows all of those styles is incredibly tricky and not something that > can be done overnight. If someone has suggested such an overarching design, > I have yet to see it. The simple solution to this for right now is to leave > multiple project handling in the domain of plugins and scripts for right > now. This means each plugin can experiment design-wise without impacting the > users of another plugin. Over time I suspect we will see a small number of > these plugins become the de-facto standard, and then at that point it is > much easier to talk about integrating the few "winning" designs into Trac > core. So, in short, if you think mutli-project support is easy and know how > it should be done, go prove me wrong. Really, I won't be offended. Make > something that everyone acknowledges is The Right Way To Do It and we can > move forward, but without that we have bigger fish to fry.
Interesting. I didn't realize it was so controversial! It seems to me that implementing http://trac.edgewall.org/ticket/1048, which is basically my suggestion from http://lists.edgewall.com/archive/trac/2005-May/002932.html, and the leading suggestion from #130 as well, would be easy and would satisfy at least some of these requirements, without precluding other different multi-project models -- so IMHO it escapes your quandary about needing one overall architecture that satisfies all comers. Also doing this in a plug-in is quite difficult. I guess I just don't see the downside to adding a Project table and related fields. (And btw this is exactly how Redmine does it; see http://forge.typo3.org/repositories/entry/team-forge/redmine/db/schema.rb). Quoting from that email: "... a good way to do this would be to continue to use a single sqlite database, but add a Projects table, and a 'project' field to tickets, versions, milestones, and anything else that's per-project. The default project (project id 0) could be the null project for compatibility, then anyone not using this feature would see no change. The Projects table could specify repository subdirs for each project; in our case they'd all be the same (top-level). Then just tweak a bunch of sql queries to use the proper Project where needed." Later on ticket model changes could allow tickets to be part of multiple projects if desired and so on -- that part is easily handled by a plugin. -- . . . . . . . . . . . . . . . . . . . . . . . . . Gary Oberbrunner [EMAIL PROTECTED] GenArts, Inc. Tel: 617-492-2888 955 Mass. Ave Fax: 617-492-2852 Cambridge, MA 02139 USA www.genarts.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
