Multiple projects, one Trac DB, one Subversion repo

[nik@…]

I have multiple, independent projects in a Subversion repo. Generally this is a mix of locally developed code and code from various open source 'vendors' to which I'm making local modifications, probably prior to punting patches back to the vendor. The repo hierarchy looks like this:

/src/contrib/sendmail/trunk/src
/src/contrib/sendmail/tags/8.13.1/src
/src/contrib/sendmail/tags/8.13.0/src
/src/contrib/sendmail/tags/{...}
/src/contrib/sendmail/vendor/current
/src/contrib/sendmail/vendor/8.13.1
/src/contrib/mimedefang/trunk/src

... similar tags/ and vendor/ directories ...
... repeat for other third party code ...

... and then for locally written stuff ...

/src/local/my-app-1/trunk/src
/src/local/my-app-1/tags/

/src/local/my-app-2/trunk/src

Each one of these is really a separate 'project', in terms of milestones, timelines, and tickets. But the same group of people can commit to them, have tickets assigned to them, and so on.

It would be great if Trac could deal with this out of the box.

I envisage it working by creating a new entity (table) for projects, with a project ID, a project name, and a path in the repository.

For example, the "Sendmail Project" might have project-id 1, and the repo path is "/src/contrib/sendmail".

Tickets and milestones should then grow the ability to be associated with particular projects. This would let me run reports for "Show me all the sendmail tickets" and "Show me all the tickets for 'nik', irrespective of which project they're for".

You can sort of do this at the moment with components. But there are a couple of issues with this approach.

First, with the examples above, each one consists of multiple components already. For example, Sendmail has a "SMTP daemon" component, a "libmilter" component, a "build" component, a "test" component, and so on.

Second, there's no way to use 'simple' component names, they need to be fully qualified. So Sendmail's "test" component has to be called "sendmail-test", MIMEDefang's has to be called "mimedefang-test". This isn't very pretty, and runs into problems when you have some third party code that conflicts with this naming scheme (e.g., a hypothetical application called "foo-test"…).

I could do this with multiple Trac databases/environments. But then I have to duplicate my user accounts and permissions across all of them, and ensure they stay in sync. It's also not possible to have a 'dashboard' page for a user which shows all their tickets across all the different projects. A user who's trying to find out what open tickets they have has to visit each project in turn.

I suspect this can be generalised. Given an implmentation that allowed "projects" to have an arbitrary number of child projects, components would just become child projects of a master project. This would also let me create "meta projects" that don't necessarily reflect the structure of the repo. For example, I could create a "mail server" project that had, as sub-projects, the sendmail code, the mimedefang code, and any locally written code related to mail servers.

[nik@…]

Looking through the tickets I see similar requests would be covered by the functionality described here; #586, #548, #234 (sort-of), #130

[Christopher Lenz]

While your description of the requirements is very helpful, this ticket is really a duplicate of #130.