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.

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.

Project and the Repository

We would also like to define which repository paths belong to a project. Trac 0.9 permits a trac instance to work within a single path within a repository thus making multiple Tracs/one repository possible. For multiple projects within a single Trac this would need to be extended as many projects are composed from common parts which are scattered in the repository. Projects should also be linked to a section of the Wiki which would be done using naming conventions - subpages of pages named after the project would belong to that project.

With the above relationship defined query building for the timeline and the roadmap sections become possible, choosing a project the timeline section would show activity for the defined repository paths and the related part of the Wiki. Milestones are also linked to projects so relevent milestone changes would be displayed. Tickets are also linked to a project so only relevent ticket changes would be shown.

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)

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

Selecting a project would show a timeline based on the repository paths, Wiki location etc. for that project. However we don't believe that this simple relationship between a project and a timeline holds for all projects. So, it should also be possible to use query support added to the timeline page to select repository paths and possibly the Wiki location. 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.

NOTE: There is an issue already posted to look at the bugtraq properties in Subversion. See issue #1947. Note that the only external client aside from the command line tools that supports the bugtraq properties right now (correctly) is TortoiseSVN.

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 unless multiple repositories were desired, 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 MyProjectName/…) 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 (now #11025) 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.

Multi Project Overview

Robin Bowes requested the ability to view summaries of tickets, checkins etc., accross all projects.

Given that the default project (project zero) would give the current Trac single project behaviour if this project were always available for selection then activity on all projects would be visible in one view.

What this does not allow is viewing activity across a subset of the projects.

Schema

This is a possible schema.

Permissions

If you had multiple projects, you would quite likely want to give some users access to some but not all projects. Right now, the security model doesn't allow for this. One option would be to add a "project" column to the permission table, which would be optional. If left blank, the permission would be allowed for all projects.