Sorry for the late response (and sorry for the response…), but that's not high on our priority list for now. To be honest, at least I haven't heard of a compelling case where it would make sense, and the current structure is not fit for multi-repos, i.e. currently the cost to get there doesn't seem worth the effort.

Felix,

I'm in a situation where a project delivered is a solution to the business rather than a technology tool.
And as such it involves typically changes in more than one domain:

- app server configs
- ETL solution for reconciliation
- service bus deployment
- custom java code

all these are stored in separate repos.

We are currently running TRAC, but the urge to switch is really strong. For TRAC it took some time too before the idea of the multiple SCM per project catched on.

So I think there is clearly a case when it is a desirable solution. More so given how often ppl are requesting this stuff.

Well, Trac is unique as the single project is the whole installation (at least without plugins). In ChiliProject we have multiple projects and subprojects which are integrated throughout the system. Thus, for everything that concerns my needs, it works.

If you really need multiple repositories per project, then pleases provide an actual use-case than can't be solved using sub-projects with each their own repository. As Felix said, we haven't yet heard a single compelling reason for that. Sorry to sound harsh here, but given the large amount of work required for that feature and the really small impact (if at all) it would have, I doubt that anyone will be eager to work on that in the foreseeable future.

Holger,

I think I understand that the chances of this feature being implemented are pretty slim.

It is just as with any good product redmine/chili is being adopted for more than its initially planned use.

With these posts I just wanted to reiterate the fact that this feature is in demand.

As for use case I'm sending you a private email.

Hi,

I'm in the same situation like Don - having projects which contain different Subversion repositories or even different paths inside one SVN repo.

E.g. a big software project consists of:

• svn://mydomain/common/trunk/ <- basic/kernel sources for all projects
• svn://mydomain/projects/customer/myproject/trunk/ <- sources for special projects, depending on common/trunk/
• svn://mydomain/config/customer/myproject/trunk/ <- server/client configs and scripts

Currently the only workaround is to use multiple parent-projects each containing one of the repos - which is very inconvenient and inefficient.

It's a problem which I had with Trac before, too :(

Imagine, you have dozens of customer projects each lying in sep. repos: How would you solve that (without having a hughe bunch of parent-projects)?

So, please think forward - if possible, I would help for that (have no experiences with Ruby yet, but willing to learn).

Best regards,
Chris

Adding to the same request, i've worked for the Federal University of Santa Catarina (Brazil) as a Moodle and Wordpress developer (and also many other projects). We used to have many repositories to better track our own plugins, third party plugins, themes, etc. Despite the fact that we could create a subproject for every one, it wasn't pratical to have "blanck projects", just to hold a repository. As a partial solution, we decided to use gitorious (locally installed) and dont use redmine for that.

If this kind of feature is implemented, for that use case, they would probably start adding repositories to the projects.

Just to be more clear, we already had a good amount of projects and subprojects that created as a mirror of the teams responsabilities. Just like Dom said, our projects hierarchie doesn't reflect of map as a 1-1 with softwares releases, we deliver more like solutions per project then softwares per projects.

@Eric, Felix & co.:
Are you thinking about our (user) concerns?

I can understand your way of thinking, but please accept and recognize that in really complex / big projects this 1:1 method won't work.

My current workaround with empty subprojects rises many ugly side effects: Commit messages are spread over multiple projects, changesets are spread around different independent subprojects, there's no single point to view and search the repository...

Even if ChiliProject rejects the user's demands, will it be possible for us users to develop a patch which would be tolerated by you?

Any hints and replies are welcome! Thanks in advance!

ciao,
Chris

Chris Dähn wrote:

@Eric, Felix & co.:
Are you thinking about our (user) concerns?

[…]

Even if ChiliProject rejects the user's demands, will it be possible for us users to develop a patch which would be tolerated by you?

To be honest that's not high on our priority list and we therefore haven't spent time discussing it. As this seems to be a "niche" request though it might be better suited for a plugin.

Regarding a plugin or patch: we won't do anything explicitly to avoid/forbid it, and if there are specific parts of ChiliProject that should be improved/changed to better support such a plugin/patch, we'll be glad to include those changes.

I hope this answers your questions, if not I'll be glad to clarify :-)

Hm, ok. Easy to follow.

From my experience realizing such fundamental functionalities implies big changes to the core of ChiliProject.

So I'm sure we need somebody with very deep knowledge of the core (and Ruby of course) to produce the patches needed to run such plugin.

If I would do that alone, I estimate a time between one or two years :( (first learning Ruby in depth, then trying to understand and investigate the core sources and then: start programming the patches + plugin)

The only systems realizing this functionality I know of are currently JIRA and Trac (with multisite patches).

Just another bad/sad message this day.

ciao,
Chris

Just one more thing about the situation, redmine 1.4 will include it: http://www.redmine.org/issues/779

Is there a chance to port the code to chiliproject?

Sounds interesting.

I'm afraid that the differences of the Redmine and CP code base actually are too big to just add the patches, or?

If not, I would greatly appreciate it to see this functionality in CP!

ciao,
Chris

+1 for me. I would also like to see this feature in Chiliproject.

I added a pull request on Github that adds this feature.

https://github.com/chiliproject/chiliproject/pull/178

I've only been using ruby for the last 2-3 days so I may have overlooked some stuff. I started by using the redmine diff's from this thread:

http://www.redmine.org/issues/779

I fixed up what wasn't working with chiliproject and added some additional features to work with the chiliproject sidebar.

I didn't add any of the tests at this point as I'm very unfamiliar with the ruby development environment and still trying to figure it all out. I also skipped a lot of the locals. If this has potential to be accepted I will put more work into it, but I wasn't sure if this was going to be used outside of my internal deployment for work.

Also redmine_checkout doesn't work with this feature.

-tony

Cool! I'm looking forward to see your solution in ChiliProject! That would solve some very annoying shortcomings of CP!

ciao,
Chris

Most of it was from the guys at Redmine so I can't take credit for that :).

The only bits I really changed were making sure it integrated with chiliproject and some UI tweaks.

-tony

I closed the old pull request due to some sloppiness with it. I'm new to git as well as ruby :/.

I've merged in the 3.0.10 features as well.

Anyhow the new link to the pull request is here:

https://github.com/chiliproject/chiliproject/pull/179

Here is an image that shows the new multi repository list view coupled with the redmine_checkout plugin (which is now working with some small modifications I've also put a pull request in for).

Thanks!

-tony

Can we please have it merged?

This is the ticket, I would like to propose for it to be considered for 3.3.0 : https://www.chiliproject.org/issues/971

3.3.0 has been launched in the meantime, in that issue Felix was saying it's not a priority (unclear if he means just for him or in general). I personally would really appreciate this feature, but don't have a clear preference on how to implement it. Maybe it's useful if you can confirm that the patch/pull request is still easy to apply to whatever is current?

Just pinging again to have it selected for the next version

+1 for this feature

with the latest ChiliProject, I tried the pull request 179 for multi repo

but encounter some problem:
https://github.com/chiliproject/chiliproject/pull/179#issuecomment-12451675

Hi,

that looks awesome! Maybe Felix could help solving the permission prob.

But is it possible to build a small test for it? So verifying is more easy for Felix & Co.?

Maybe this would motivate the devs to prioritize this pull request - we know they're flouded with work...

Thanks and: Great work! Would love to see this in 3.6.0!!!

I try to test this patch on a copy of a bigger production system this week... so you have more testers ;-)