Redmine

We would also like to be able to have multiple repositories per project. A "Project" doesn't always mean that your using one set of code.

I add another example.
We use two repositories for one project.
One is for sources, another is for documents.
And documents repository is common for each projects.

So I hope Redmine can manage SCM independently from "Project".
I think setting relations between "Project" and "SCM" is better way.

We also have the need to have multiple projects use the same SCM. Redmine can currently do this but it imports the commits multiple times each project. This is ok but the ability to "share" SCM across project would be nice.

Just echoing the requirements above. Ideal would be to move repositories to be a top level object which could be linked to one or more projects independantly.

I make a patch for ad-hoc solution. (for r1291)
#Maybe issue got illegal data on regular Redmine. (Currently maybe no effect.)

Maybe there are a lot of faults in this.
However, it show what want to do.

This can do only:

Another project's SCM changeset comment effect another project's issue.
"refs #**" , "fixes #**" and like them.

• make SCM crawler projects. No issue management.
• make Management project.
• Commit with comment, and SCM project's repository updated, then you can get associated revisions on the issue.
  #scheduled fetch_changeset is better way.

Hello,

Any updates on this request? I'm also interested in hearing whether this will be incorporated into a future release/plugin.

Thanks,

Clyde

This kind of feature leads to very deep changes in redmine architecture and ergonomy. Worst of all: data migration would be a real pain. The common usage of multi-SCM can't be replaced by sub-projects?

Can sub-project SCM's comments effect parent's issue?
Can all SCM adapters handle same repositories in another project?(CVS doubt).
If above 2 issues become clear, I can accept.
(I don't know my usage is common or not :) )

Aruo Miura wrote:

Can sub-project SCM's comments effect parent's issue? Can all SCM adapters handle same repositories in another project?(CVS doubt). If above 2 issues become clear, I can accept. (I don't know my usage is common or not :) )

For me I don't see the need for multiple SCMs. But I would like support for branching in all of the SCM adapters. For me particularly the Git adapter. For example, ticket #1387 and this forum post - http://www.redmine.org/boards/1/topics/show/999. YMMV.

I understand Thomas Lecavalier when he says that it will lead to deap changes in redmine architecture.
Is it possible to open a new development branch in Redmine for this kind of feature ?
I'm affraid I don't have the necessary skills to develop such a feature and to dive into redmine architecture =(

Sub-projects are not a replacement for seperate repository management.
Think of a project that has multiple (let's say more than 3) svn repositories with some of them shared with other projects.
Maintaining a hierarchical project organisation will quickly become a nightmare.
Also think about events and comments propagations between parents and children projects that will became a hassle to understand -> see Aruo Mirua's questions

Last point : Thomas, you say that data migration would be a real pain.
I don't understand why if you manage your repository seperatly with their backup strategy.

Could you please be more precise on that point?
Thank you.

Jonathan Dray wrote:

I understand Thomas Lecavalier when he says that it will lead to deap changes in redmine architecture. Is it possible to open a new development branch in Redmine for this kind of feature ? I'm affraid I don't have the necessary skills to develop such a feature and to dive into redmine architecture =(

A new development branch would be possible but it will need to be done by someone with a lot of time. The main branch progresses rapidly, so the Multiple SCM branch will be very busy keeping up on the mainline changes in addition to implementing their feature. Git could migrate some of the merging issues, since Subversion doesn't track branches.

Last point : Thomas, you say that data migration would be a real pain. I don't understand why if you manage your repository seperatly with their backup strategy.

In order to have multiple SCMs, several parts of the underlying database schema will need to be changed and data will need to be shuffled around. I assume you have a great backup strategy but I've seen many, many people just update software without a backup. If there is even the slightest error, their installation is broken and they blame the project.

I see this being a useful feature, especially in the use case you gave above. I don't have the time myself to work on it but if you create a branch and start on something, I'm sure others will help out. I see at least 5 people interested in this issue alone. JPL might be able to give you svn access to create a branch or you can fork my GitHub repository.

Eric

I made a executable script for multiple CVS modules per project.
It wraps cvs command, and modifies the output from cvs command.

• save the attached script cvs_alias.rb onto your server.
• register a virtual module name in Repository of the Project in Redmine.
• edit cvs_alias.rb, modifiy the constant ALIASES that associates virtual module name and real module names, and modifity CVSROOT as your environment.
• edit "lib/redmine/scm/adapters/cvs_adapter.rb", then modify the constant CVS_BIN to /path/to/cvs_alias.rb.

Another vote from me for this functionality. It would be very useful.

(Although #1387, support for branches in git repositories, might make up a bit for the lack of multiple repository support)

Matthew W wrote:

Another vote from me for this functionality. It would be very useful.

(Although #1387, support for branches in git repositories, might make up a bit for the lack of multiple repository support)

More one vote here.
It's the only issue that is blocking my company to use redmine... =/

Willen Silva wrote:

Matthew W wrote:

Another vote from me for this functionality. It would be very useful.

(Although #1387, support for branches in git repositories, might make up a bit for the lack of multiple repository support)

More one vote here. It's the only issue that is blocking my company to use redmine... =/

Hi,

I think this feature would be a great step forward. We are using different (subversion) repositories to separate code from other project documentation.

Having several repositories would help to get a complete picture.

Thanks Ralf

More one vote here. It's the only issue that is blocking my company to use redmine... =/

I think this feature would be a great step forward.

+1

Definatly something we miss in our redmine setup here at work.

+1

+1

+1

+1

+1
I have the case where the primary repo is in CVS on SF.net and my fork is on mercurial on another server. Being able to see both in redmine would be lovely.

I also think this is useful. I actually need for my projects, cause, all they use two or three repositories, even from different SCM.
And i was reading this, i think that global repos, cold wait for a more develop design, but (let's say this, DON"T KNOW ALMOST ANYTHING ABOUT REDMINE INTERNALS) i think that multiple repos for projects can't be extremely difficult or so for redmine's developer.
By the way, GREAT JOB on Redmine.

+1, I think...

I think my problem fits into the scope of this request... we maintain several products in
a single repo, but products share code & are branched too:

    /trunk/productA
          /productB
          /sharedA
          /sharedB
          /sharedC

    /releases/productA-1-0/productA
                          /sharedA
                          /sharedB
                          /sharedC

             /productB-2-0/productB
                          /sharedC

All products live together in /trunk & each uses a different subset of the shared pieces.

Products are branched into /releases along with the code they share.

There's no single place to point the base of the project repo at that makes sense - the best
compromise is pointing at the root of the repo so that every project sees every change. This
would flood each project with unrelated commits.

For our purposes, some kind of filtering system might suffice?

I think Bob Roberts has provided a patch in issue : #3087

This allows to run multiple SCMs against one issue location
- root project has issues module enabled, repository module disabled
- subprojects have issues module disabled, but repository module enabled

Subprojects receive repository updates, and they can refer/close parent project issues.

Kind regards

+1

Using subprojects with repo but no issues seems a bit messy, but might be workable... Is there any work being done on this feature at present? Or plans to include #3087 in a future release?

+1

+1

+1

+1

David Petersen wrote:

We would also like to be able to have multiple repositories per project. A "Project" doesn't always mean that your using one set of code.

+1.

I have configured my subprojects as "categories" (example, "core","selector" etc). Then I have multiple repositories for "one" project... this feature is blocker for me.

Any change to have in next 0.9 release?

dedalus - wrote:

Any change to have in next 0.9 release?

0.9 features are freezed.

Jean-Philippe Lang wrote:

0.9 features are freezed.
Then I hope for next 1.0 release... meanwhile I continue to use readmine :-D

+1

We use multiple SVN repositories (URLs) per project.

ProjectA:
http://host/common/trunk
http://host/projectA/trunk

ProjectB:
http://host/common/trunk
http://host/projectB/trunk

Can this not be adequately solved with sub-projects?

+1 for version 1.0

We have many projects, but they all use the same CVS repository and its HUGE with thousands of branches and commits spanning many years. Importing the whole thing for every project is a big problem.

+1

+1 Adding this feature would eliminate another roadblock in my corporate environment.

+1 for version 1.0

We have one repository for each development project, since we otherwise would have lots of overlaps. Redmine projects, however, span multiple such development projects... This would really be a cool feature for 1.0.

+1

+1

+1

Trac 0.12 has this feature...
http://trac.edgewall.org/wiki/TracRepositoryAdmin