[patch] add support for multiple repositories

[David Kühling <dvdkhlng@…>]

Trac 0.12 supports multiple repositories per environment. When using multiple repositories, each one is assigned a name, to identify it in the Trac browser. These names are used like path prefixes so a trac URL "trac/browser/repo/a/b" may refer to path "/b" in a repository named "repo/a". The repository named "(default)" is used for paths not matching any of the repository names.

Bitten currently (as of r1010) only searches for paths in the repository named "(default)", i.e. does not support more than one repository.

Patches to add multi-repository support have been attached to ticket #342 (which is originally about DVCS branch-name issues) and where updated for 3 years now. Let's pull these patches into this new ticket. The latest, updated multi-repository patch against r1010 is attached.

[David Kühling <dvdkhlng@…>]

Add support for handling multiple repositories, properly interpreting paths prefixed with a repository name. This is the same as patch t342_multi_repos_r1010.patch from ticket #342.

[fbrettschneider@…]

What is star * supposed to do in repository.py line 60?

href = req.href.browser(*resource.id, annotate=annotate, rev=resource.version)

Removing * seems to help.

But I also noticed that the master sends the revision number of the (Standard) repo instead of the proper revision number of the repo given by slave (repository.branch). Maybe this is reasoned by the * above, isn't it?

[falkb <fbrettschneider@…>]

Replying to fbrettschneider@…:

But I also noticed that the master sends the revision number of the (Standard) repo instead of the proper revision number of the repo given by slave (repository.branch).

Now I've found out the wrong revision number was reasoned by a previous misconfiguration of my Bitten build configuration (see webinterface: Admin->Builds->Configuration->Manage Build Configurations):

1. First I set the wrong repository "trunk" of the default repository and started the slave which got about 20000 builds scheduled.
2. Then I noticed my mistake and aborted the slave after a few builds. But the scheduled number of builds (= 20000 minus a few) remain in the database.
3. I corrected the repository path to "secondrepo/trunk" and started the slave again.
4. But the slave still tried to process all the old (wrong) builds because they were scheduled first.

=> I solved this problem by removing the whole Build Configuration which clears the database from all records of it. Then I setup a new proper Build Configuration and now the patch works well for me also.

[anonymous]

+1 for applying this patch

[hodgestar]

If someone can add tests to the patch I'll look at landing it.