Redmine

I would like to second this feature request. At work we have three repositories for one of our projects. One contains our platform independent software platform and the two others contain toolchains and platform specific code for the hardware platforms that we support.
Most bugs are related to our own software but some are fixed in one of the toolchain repositories and it would be nice if they could all reference the same master project.

I'm also looking for this feature.

In my case projects are using several folders of the same repository (a subset of all the folders available).

I've a workaround :
First of all, create a new project ProjectB, who will be a sub-project of ProjectA
and in Modules panel only enable repository, if you just want an other repository of course ;)
Finally download and apply my last patch of Issue #3346

Now, when you are in ProjectA, you can link to your second repository with this wiki syntax : r:ProjectB:r1 or commit:ProjectB:a85130f

I think your patch answers previously asked for feature:
#3216 - ability to link commit/revision across projects through wiki

On a related note, there was some work done on nicer handling of a project with multiple repositories (with patches):
#3087 - Commit on one project can reference issue from another, related, project.
#3376 - Commit properly linking across projects (when issue is moved, or through #3087)

Basically, make parent project with issues. Make children projects with repositories (without issues). Now your parent project will feed children commits and close your issues.

Kind regards

Adam Żochowski

I would vote for this, too. Especially for Git repositories -- since you can only checkout whole repositories, more smaller repositories makes sense. I think this sub-project model makes good sense, too.

The patch in #3346 sounds very interesting, as the ability to do cross project repository source links is something I'm very interested in.

However, the main thrust of this request is the ability to associate revisions from multiple repositories, which I now have working well.

The patch in #3087 allows linking repositories and parent project repositories, and I've now updated that issue with a slight change that allows revisions in any tracked repository to be associated with issues in any project, which for most practical purposes allows unlimited repositories per project.

--Bill

I'd vote for this too. Creating multiple sub-projects if we have multiple repos is quite a hassle. I wanted to move our support issue tracker over to redmine but we have about 12 repos and creating 12 sub-projects in order to allow us to see the changesets associated to issues is really troublesome.

I would vote for this feature too. Given for instance a software containing many small components each with it's own repository and distribution mechanism. Then a single project that would require a series of small modifications of a subset of these components does not need to open a new sub project for every component. Especially if several different repository types have to be mixed within one project.

Marc Mengel wrote:

Especially for Git repositories -- since you can only checkout whole repositories, more smaller repositories makes sense. I think this sub-project model makes good sense, too.

In the special case of a distributed vcs like Git et al this is obviously useful to track multiple developers forks which are to be merged back into a main project.

I also want to add that it is currently not possible to relocate a repository url (eg if it changed the hoster). Of course one should keep in mind that there may be references to commits in the issues and comments (eg "Code Review" plugin makes heavy use of that) and these links need to be rewriten which may be impossible if you not only move to another host but also move to another vcs. This is where having multiple repositories per project comes in handy. One should be able to define some sort of translation mapping from old commit ids to new ones and optionally freezing the old repository url so it can no longer receive new commit links.

I would definitely vote 'yes' for this feature.
We create subprojects to cover multiple repositories, but this is not the right way to do things ;)

Since we have several repositories for single project, I would vote for this feature too.

vote yes for this feature

+1

I vote yes for this feature too, we have several repositories for a project.

+1

+1

Issue 779 is a duplicate of this one and has more activity, perhaps its worth closing this and directing all comments to that issue instead.

+1

+1, would be nice to have seperate repos for hardware and software aspects of a project

+1

+1

+1

+1

We would use this feature to have on repsoitory for source code (developer team)and one one for documentation (analysts team), where the the last one will accessivle via webdav from windows explorer (http://www.redmine.org/projects/redmine/wiki/PluginWebDav).

The read/write rights per repository should be setable per role.
+1

I disagree that repo permissions should be part of redmine - they are something that should be set in SVN itself. Redmine just provides the links to the repo.

Still, it's another example why there should be multiple repositories per project.

I implemented the patch, it works for the general case, but it does not work with many plugins that expect a single repo. So I think this really needs to be added to the main codebase.

Also, can we close this bug and add everything to bug #779 which is the original report for multip repos per project.