Merging multiple tracs to a mercurial forest

[Chris Mulligan]

Hi folks (particularly Christian),

We have about 10 Trac installs running, mostly on a single machine but
some on others. They're all on 0.10.4 right now. There are only about
5 that are high volume, and only some of them have subversion
repositories.

We're interested in merging our repositories and tracs down to one or
two instances. To help with this we're considering migrating all the
repositories to a Mercurial forest and merging the wikis and tickets
to a single Trac. I'm not especially concerned with merging the
tickets, etc. A little bit of sick creativity (trac 1 ticket #300
becomes #1300, trac 2 ticket #60 becomes #2060. Wiki conflicts become
wiki/trac1/Conflict and wiki/trac2/Conflict) and we should be good to
go.

Our main issue is trac hg forest support. I see that it's not really
supported at TracMercurial, but I also seem some recent activity. A
checkout just now of 0.11b2, multirepos and TracMercurial 0.12 isn't
working (it sees no revisions at the forest level). Is forest support
being developed now? Is there something we can do to encourage its
development?

Thanks,
Chris

[Christian Boos]

Hello Chris,

Thanks for your interest in the multiple repository support!
A couple of remarks: if you use the multirepos branch, you don't need to
have 0.11b2 around - just install Trac from that checkout.

Also, you don't necessarily need to convert your Subversion repositories
to Mercurial, as "mixed" backends are supported. However there's no
cache yet (so for Subversion you'd have to use the direct-svnfs type).
An enhanced vc cache layer will be the next step, and if you have big
repositories, that will really be needed (unless you have a /really/
beefy server ;-) ).

As for the forest support, well, that's just a few lines of code away
and Ido Sebastiaan van Oostveen even started the effort a few months ago
- see http://hg.trbs.net/), so this just needs to be finalized.

On a related note, I think you're attempting this project consolidation
in order to be able to have a global overview of the activity of the
different projects, sharing common knowledge in the wiki, consolidated
search and queries, this sort of things. But won't you lack the ability
to have more focused "views" about what's going on? In particular, one
of the risks is that you'll get lots of information in the timeline,
which has currently no good filtering capabilities. I ask this because I
start to feel the need to go in the opposite direction (split a big
project into multiple ones), but of course with keeping the possibility
to have an overview when needed. So I'll soon start to work on multiple
project support, which should complement the multiple repository support
(each project will have one default repository and possibly others, like
the single project currently do in the multirepos branch). Migrating
multiple projects into one won't even require sick creativity in this
setup ;-)

-- Christian

[Chris Mulligan]

 Thanks very much for your reply.

Yes, that is a concern. We haven't fully committed to doing this yet, but we know that our current system does not work. There are several code bases that are in subversion but have no Trac. The last thing we need is to go from 10-20 Trac installations which each have only a few wiki pages and a dozen tickets. Each project is somewhat unique, but there are tons of inter-dependencies and many developers are working on multiple projects at once.

Has anyone considered a plugin to add timeline filters? I can imagine doing somewhat robust system where you define a certain wiki namespace (eg wiki/Bitten), set of components and milestones, and subversion paths for implicit filtering, perhaps in addition to a more hard coded system link GenericTrac.

Has anyone else done work on sub projects or multi project situations that are worth looking at?