Handling Multiple Projects

We have been looking very closely at Trac and how we would use it in a multi project environment. Our conclusions are a little different to any of the proposals made so far. The Trac philosophy is to keep things as simple as possible while preserving flexibility and that is what we are trying to do.

We have a large code base. Much of that code is shared among a large number of projects. There is also a complex relationship between projects and milestones. For example, a milestone may change common code and result in several project releases. In other cases there is a one to one milestone/project mapping.

What the above means is that the relationship between a milestone, projects, timeline etc. can get quite complex. The issue is how to deal with that while providing a clean and understandable system which normal people can cope with. Neither of the other proposals for handling this (TracMultipleProjects/MultipleEnvironments and TracMultipleProjects/SingleEnvironment) deal with this complexity. We believe that TracMultipleProjects/MultipleEnvironments is a non-starter for this. There are some good ideas in TracMultipleProjects/SingleEnvironment which are extended by this proposal.

Requests like the one in #1048 and #586 are too simplistic as they only address multiple projects which have nothing in common.

Trac Data

Gary Oberbrunner made these suggestions on the mailing list:

• 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)

We would like to extend this so that:

• Milestones can be linked to more than one project. This would require an extra table to link milestones and projects.
• Milestone names would live in a flat namespace because of the above. I.e., Garys milestone naming proposal only works if there is a one to one relationship between project and milestone.
• Queries should support selecting multiple projects.

Ticket Changes

• A project field drop down list.
• A project version field drop down list which depends on the project field (i.e., each project has it's own set of versions). The current version field would become this field.
• The existing component field has to be dependent on the project. Each project will have it's own set of components, or, the component field could be optional so that those with multiple projects can remove it.
• The milestone field also has to be dependent on the project (selecting a project would only show milestones which are relevant to that project)

Somehow milestones have to be associated with projects (maybe more than one project). Adding a milestone would entail selecting a list of projects affected by that milestone.

Timeline

We don't believe that there is a simple relationship between a project and a timeline. We think that instead of switching the timeline based on the selection of a project that there should be query support added to the timeline page. These queries should allow the user to select a number of paths into the subversion repository to select repository checkins, a project choice to select tickets and milestones, and a Wiki path (or number of Wiki paths) to select Wiki pages (see Wiki section below). These queries should also be saved so project teams can build reports which are useful for their project. Using these queries most users requirements should be covered. Maybe the queries should be saved by project or milestone - that would be good but not strictly necessary.

In an ideal world there would be a way to link subversion commits to a project. This could be done using the bugtraq string which TortoiseSVN adds to a commit. The bugtraq id links to a ticket which is against a project. Perfect timelines then! The downside of this is that *every* commit *has* to specify a ticket. The Trac code which indexes repository revisions would have to search commit messages for the bugtrac id and link it to the ticket. I guess Trac could then log the commit in the ticket as well.

Roadmap

This is rather simpler than for the timeline. Given that there needs to be a defined relationship between projects and milestones selecting a project should be all that is needed.

Browse Source

No need to change anything here as it is and should remain a view of the entire repository content.

Wiki

I think that by using the subpages or whatever it is you call pages which have a path (like TracDev/…) with the project name at the top level would neatly support multiple project documentation. The query for the timeline would use this path name to select project documentation changes.

Tickets Affecting Multiple Projects

Ticket #130 talks about assigning one ticket to multiple projects. I believe that this would be complex and prone to error. It is very difficult to know which projects a piece of common code will affect. It would be very useful to be able to have tickets depend on other tickets (see ticket #31) so that as problems are found on different projects which are caused by common code they can be linked to a single ticket.