Project

General

Profile

Actions

Feature #779

closed

Multiple SCM per project

Added by Jonathan Dray about 16 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Category:
SCM
Target version:
Start date:
2008-03-04
Due date:
% Done:

80%

Estimated time:
Resolution:

Description

It would be nice to have multiple scm per project.

A few strategies are available :
- put all the code in the same repository.
- manage each program in a seperate repository.

For a project, users should have the choice how to organise and manage versionning.


Files

IssueRepositoriesGrobal.patch (2.33 KB) IssueRepositoriesGrobal.patch patch of ad-hoc solution for support multiple SCM "like". Aruo Miura, 2008-03-26 08:09
cvs_alias.rb (1.91 KB) cvs_alias.rb minoru fukuda, 2008-06-26 11:05
0001-.patch (15.4 KB) 0001-.patch yusuke kokubo, 2010-10-28 04:49
0055-multiple-SCM-fix-navigation.patch (1.23 KB) 0055-multiple-SCM-fix-navigation.patch Luis Garcia, 2010-12-07 20:43
0001-Multiple-SCM-per-Project.patch (16.3 KB) 0001-Multiple-SCM-per-Project.patch yusuke kokubo, 2011-01-06 09:08
multi_repo.patch (23.3 KB) multi_repo.patch Robert Gruendler, 2011-01-06 12:32
002_multi_repo.patch (34.9 KB) 002_multi_repo.patch Robert Gruendler, 2011-01-13 13:59
fix-broken-rev-link.83fae10224d087.diff (906 Bytes) fix-broken-rev-link.83fae10224d087.diff Toshi MARUYAMA, 2011-01-18 15:39
svn-schema-check.png (37.3 KB) svn-schema-check.png Toshi MARUYAMA, 2011-01-18 16:05

Related issues

Related to Redmine - Feature #4052: Cross-project redmine links with alternate link text for source and export links.New2009-10-19

Actions
Related to Redmine - Feature #3687: Possibility to link all projects to a single SVN repositoryNew2009-07-29

Actions
Related to Redmine - Feature #7409: Cross project Redmine linksClosed2011-01-22

Actions
Related to Redmine - Feature #8826: support for multiply repositories representing the single projectClosed2011-07-15

Actions
Related to Redmine - Defect #3087: Revision referring to issues across all projectsClosedJean-Philippe Lang2009-03-31

Actions
Related to Redmine - Feature #3346: Support for cross-project revision linksClosed2009-05-12

Actions
Related to Redmine - Feature #9703: Define repositories independently from projectsNew

Actions
Related to Redmine - Defect #10026: Git: Mercurial: Branch dropdown broken on repositories pageClosedJean-Philippe Lang

Actions
Has duplicate Redmine - Feature #1172: Multiple repository modulesClosed2008-05-05

Actions
Has duplicate Redmine - Feature #3169: Multiple repositories for projectsClosed2009-04-14

Actions
Actions #1

Updated by David Petersen about 16 years ago

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.

Actions #2

Updated by Aruo Miura about 16 years ago

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.

Actions #3

Updated by David Petersen about 16 years ago

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.

Actions #4

Updated by Richard Nichols about 16 years ago

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.

Actions #5

Updated by Aruo Miura about 16 years ago

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.

usage:
  • 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.
Actions #6

Updated by Clyde Goffe almost 16 years ago

Hello,

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

Thanks,

Clyde

Actions #7

Updated by Thomas Lecavelier almost 16 years ago

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?

Actions #8

Updated by Aruo Miura almost 16 years ago

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 :) )

Actions #9

Updated by James Turnbull almost 16 years ago

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.

Actions #10

Updated by Jean-Philippe Lang almost 16 years ago

  • Subject changed from Multiple SCP per project to Multiple SCM per project
Actions #11

Updated by Jonathan Dray almost 16 years ago

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.

Actions #12

Updated by Eric Davis almost 16 years ago

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

Actions #13

Updated by minoru fukuda almost 16 years ago

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

Usage:
  • 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.
Actions #14

Updated by Matthew W about 15 years ago

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)

Actions #15

Updated by Will Silva about 15 years ago

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... =/

Actions #16

Updated by Ralf Petersilka about 15 years ago

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

Actions #17

Updated by Daniel Svensson about 15 years ago

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.

Actions #18

Updated by Nicklas Holm about 15 years ago

+1

Actions #20

Updated by Nicolas Maeder almost 15 years ago

+1

Actions #21

Updated by Oskar Nordquist almost 15 years ago

+1

Actions #22

Updated by Ollivier Robert almost 15 years ago

+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.

Actions #23

Updated by Erick Pérez Castellanos almost 15 years ago

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.

Actions #24

Updated by Daniel Moore almost 15 years ago

+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?

Actions #25

Updated by Adam Piotr Żochowski almost 15 years ago

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

Actions #26

Updated by Seth Dziengeleski almost 15 years ago

+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?

Actions #27

Updated by Robert Prince over 14 years ago

+1

Actions #28

Updated by Jiongliang Zhang over 14 years ago

+1

Actions #29

Updated by Yelve Y. over 14 years ago

+1

Actions #30

Updated by Roman Musin over 14 years ago

+1

Actions #31

Updated by pasquale [:dedalus] about 14 years ago

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?

Actions #32

Updated by Jean-Philippe Lang about 14 years ago

dedalus - wrote:

Any change to have in next 0.9 release?

0.9 features are freezed.

Actions #33

Updated by pasquale [:dedalus] about 14 years ago

Jean-Philippe Lang wrote:

0.9 features are freezed.

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

Actions #34

Updated by Daniel Beland about 14 years ago

+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

Actions #35

Updated by Pieter Smith about 14 years ago

Can this not be adequately solved with sub-projects?

Actions #36

Updated by Pascal Schoenhardt about 14 years ago

+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.

Actions #37

Updated by armin walland almost 14 years ago

+1

Actions #38

Updated by Tim Henigan almost 14 years ago

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

Actions #39

Updated by fnord 999 almost 14 years ago

+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.

Actions #40

Updated by Uli Köhler almost 14 years ago

+1

Actions #41

Updated by Thomas L. Kjeldsen over 13 years ago

+1

Actions #42

Updated by yusuke kokubo over 13 years ago

Actions #43

Updated by Richard Hurt over 13 years ago

+1

We are also looking to track multiple repositories for a project. I'm not saying that it will keep us from using Redmine, but it sure would be a great feature point compared to other products.

Actions #44

Updated by Fardeen GHULAM over 13 years ago

+1

We are very interested also in this feature. It would avoid to have only one huge repository containing everything...

Actions #45

Updated by yusuke kokubo over 13 years ago

This is a very very adhoc patch to able to have Mutliple SCM per project.
(still incomplete)

Please try it and review it.

Actions #46

Updated by Eric Thomas over 13 years ago

yusuke kokubo wrote:

This is a very very adhoc patch to able to have Mutliple SCM per project.
(still incomplete)

Please try it and review it.

Tests...?

Actions #47

Updated by yusuke kokubo over 13 years ago

Eric Thomas wrote:

Tests...?

no yet...

Actions #48

Updated by Billy T over 13 years ago

+1
It also fix our problem.

Actions #49

Updated by Giovani Vizzotto over 13 years ago

+1
We are very interested also in this feature.
We use REDMINE for electronics development, so we have multiple repositories, one for each development area:

    /ProjectA
          /DocumentsA
          /Hardware
                     /HardwareDocumentation
                     /Board1 (repo1)
                     /Board2 (repo2)
                     ...
          /SoftwareA
                     /SWBoard1 (repo3)
                     /SWBoard2 (repo4)
                     ...
          /FpgaA
                    /Fpga1 (repo5) - Board Especific
                    /Library1 (repo6)..
                    /Library2 (repo7)..
                    ....

          /MechanicalA
          /SystemIntegrationAndTests

Each product can have more than one PCB, each PCB usualy have a processor and/or FPGA.
We do a great reuse of the code and boards between diferent projects. So we need to mantain all the pieces "glued" together.

Currently, we use REDMINE sub-versions, one for each development area (Documents,Hardware, Software, FPGA, Mechanical, System).

Is not practical to open one sub-project for each repository.

So we try to use the SVN:Externals property to link the repositories, but doesn't work ( http://www.redmine.org/boards/1/topics/19639 ).

But the solution of multiple repositories per project is more generic.

Actions #50

Updated by Luis Garcia over 13 years ago

Hi. I am also very interested in this feature.
I am responsible for LliureX (an Ubuntu derivative distribution for education). Currently we are thinking about moving our svn+trac to bazaar, so support for multiple bazaar branches per project (like this patch or #2799) are features we absolutely need.
Your patch works great for us! I had noticed just a small problem when clicking 'root' and directory links in the repository title links. The links revert to 'default' repository (index 0) due to absence of 'rid' parameter.
I think that the (very simple) attached patch fixes it, and can be added to your code.
Sorry about the code (and for my english too!), but I have absolutely no familiarity with ruby on rails, so feel free to modify it as you like.

You can count with me for testing.

yusuke kokubo wrote:

This is a very very adhoc patch to able to have Mutliple SCM per project.
(still incomplete)

Please try it and review it.

Actions #51

Updated by Damien Couderc over 13 years ago

+1

Actions #52

Updated by Takumi TSUKINAGA over 13 years ago

+1

Nice patch.thanks.

Actions #53

Updated by Ivan Cenov over 13 years ago

Hi,

This feature would be very useful. Our projects use multiple svn repositories:

Project
  sw                    -- software
  el                    -- electronics, electrotechnics
  mech                  -- mechanical costruction
  doc                   -- text documents (tech specifications, test result protocols, bills of materials ...)
  ud                    -- User documentations (manuals)
By now, we create 'Project' and several subprojects with names 'Project-sw', 'Project-el' and so on. This way works but the number of the projects grows very fast and the system becomes not so easy to handle with.

On the other hand, multiple repositories for one project would make Redmine very complicated. It would be a big development effort... and I'm afraid that Redmine may become too heavy to develop and maintain.

Ivan

Actions #54

Updated by Robert Gruendler about 13 years ago

is this patch working for for anyone on redmine v 1.1.0 ?

i'm getting these errors with git:

git apply --check 0001-.patch
error: patch failed: app/controllers/repositories_controller.rb:199
error: app/controllers/repositories_controller.rb: patch does not apply
error: patch failed: app/helpers/application_helper.rb:105
error: app/helpers/application_helper.rb: patch does not apply
error: patch failed: app/helpers/repositories_helper.rb:87
error: app/helpers/repositories_helper.rb: patch does not apply
error: patch failed: app/models/changeset.rb:161
error: app/models/changeset.rb: patch does not apply
error: patch failed: app/views/repositories/_dir_list_content.rhtml:12
error: app/views/repositories/_dir_list_content.rhtml: patch does not apply

Actions #55

Updated by yusuke kokubo about 13 years ago

updated the patch for trunk ( r4642 )
  1. still adhoc...

Luis Garcia

Thanks your try and review.
this new patch including your code.

Actions #56

Updated by yusuke kokubo about 13 years ago

updated the patch for trunk ( r4642 )

sorry.
latest update of trunk is r4636

Actions #57

Updated by Robert Gruendler about 13 years ago

Sorry, i did not notice your replies and in the meantime i've fixed the first patch and merged the second one into it. Also, i've added some features/fixes:

  • Added a name field to the repository model - repos can be named now so they don't show the full path to the repo
  • Fixed sys_controller > fetch_changesets so people who fetch the changesets this way can use the patch too

I've created a multi_repo branch on my github account, where i will maintain those changes as long as they are not merged into trunk.

I'd like to note that i'm no ruby/rails developer either, and i've only tested my changes on git repositories, but they should work on all other supported scms too.

Maybe we can work on this patch together on github/sourceforge/etc, so we don't have to manually merge fixes/additions of each other manually.

Actions #58

Updated by Robert Gruendler about 13 years ago

i've updated the generalized unit tests in my github fork, but i couldn't fix the repository-specific tests, as i think they need certain local repositories to test against. Anyone knows if these tests are documented somewhere?

Actions #59

Updated by Toshi MARUYAMA about 13 years ago

Actions #60

Updated by yusuke kokubo about 13 years ago

Sorry, i did not notice your replies

Please do not worry about my update.

i will maintain those changes as long as they are not merged into trunk.

Thanks your work.

below is memo in Japanese.

将来、自分のパッチが起点となってこの機能が本体にマージされることになるのなら

私としては光栄に思います。
(アドホックなコードなのでtrunkにマージされるころには跡形もなくなっていそうですが…)

Actions #61

Updated by Toshi MARUYAMA about 13 years ago

I am Japanese, too. I write a memo in Japanese.
私も日本語で。
私もこのissueを見ていました。このパッチとコンフリクトすることは承知でコミットしました。
申し訳ございません。

Actions #62

Updated by yusuke kokubo about 13 years ago

in Japanese.

私もこのissueを見ていました。このパッチとコンフリクトすることは承知でコミットしました。
申し訳ございません。

全然問題ないので気にしないでください。
わざわざパッチを1つ1つ気にしてたら作業できませんからね。

Actions #63

Updated by Robert Gruendler about 13 years ago

Toshi MARUYAMA wrote:

Please see source:tags/1.0.5/doc/RUNNING_TESTS#L16 .

thanks. I have managed to create all scm test repositories, install the required scms and run all the tests. Some of the repository specific tests have errors, but i'm not sure if they're related to the patch, because all of the tests create the repository object under test like this:

  def setup
    @project = Project.find(1)
    assert @repository = Repository::Bazaar.create(:project => @project, :url => "file:///#{REPOSITORY_PATH}")
  end

Also, the cvs tests fails with this error:

Loaded suite test/unit/repository_cvs_test
Started
.Unknown command: `rls'

Not sure if i can fixe these ones.

Actions #64

Updated by Toshi MARUYAMA about 13 years ago

cvs version requires version 1.12.
darcs test passes in version 1.0.9.
You can download at http://eric.kow.free.fr/download/darcs-1.0.9-i386-linux.gz .

Actions #65

Updated by Andy Bolstridge about 13 years ago

I'd like to add a little inout here : this is a great addition to the project. Where I work, we have a single repository but multiple paths. ie. each version of our product is branched, but this is not in a single root that's meaningful to associate with a redmine project.

What I'd love to see is the ability to set a repository for each version within a project. I can add versions to a redmine project, but they are just text. Adding a link to the subversion repo would solve all our problems and I think would not complicate the basic design of redmine at all.

There's already a link to a wiki page for each version, so why not add a link to a repo (including path).

Actions #66

Updated by Robert Gruendler about 13 years ago

Couldn't this be solved by adding the link to the repo/path in the wiki page of eaach version? Maybe i don't understand you correctly.

Actions #67

Updated by Andy Bolstridge about 13 years ago

It could be a link in a wiki page - but that's just tucking it away where no-one will see it.

Imagine the usual subversion organisation of a repository with the trunk/tags/branches directory structure. I'd like to be able to set the trunk folder path in the project main repository, but then if I had 1 redmine version mapped to a subversion tag folder, then I'd like to put a link (that's a lot more obvious and 'in-your-face' than a wiki link) that would give you the full redmine repository page when you clicked on it. Of course, this link would only be accessible per version - like the wiki page is for each version.

so:
trunk -> set in the project main repository settings tab.
tags/ReleaseA -> set as a link in a redmine version 'Release A'.
and so on for release B etc.

then my users can get at the correct repository path for a version that they want, without having to open the main repository page and browsing through to get the correct folder.

(ok, in my subversion repo, this is more complicated as we have tag folders that are not sub-folders to a project - ie we have trunk/tags/branches at the top level and multiple projects underneath them. But the above solution would still work for me).

Actions #68

Updated by Robert Gruendler about 13 years ago

Andreas Lausenhammer: i understand your point now, makes sense.

Before i start installing up the required scms to fully test the patches, i'd like to ask the redmine developers how realistic they think it is to merge this patch into redmine trunk. As far as i am concerned, it works for us and we use it on our production redmine instance. But as i've already mentioned i'm no ruby/rails developer and i can't really say if - especially my contributions - can satisfy the redmine coding standards.

Actions #69

Updated by Damien Couderc about 13 years ago

As this request exists since 3 years and that a lot of people is waiting for it, it would really be a shame if this would not go into trunk soon.
Even if the diff does not satisfy coding standards it should not take long for a commiter to rework it as it is functional.

Happy new year.

Actions #70

Updated by Andy Bolstridge about 13 years ago

FYI, this is how Trac handles multiple repos per project:
http://trac.edgewall.org/wiki/0.12/TracRepositoryAdmin
see the example for a 'project' and 'lib' repository links within the same trac project.

Still, if Robert's patch works, I'd be very happy to see it incorporated into the main Redmine codebase, I might even have a go trying it out later with our svn repos.

Actions #71

Updated by Robert Gruendler about 13 years ago

just for the record: the patch is from yusuke, i just added some minor stuff and am maintaining it on github.

Actions #72

Updated by Andy Bolstridge about 13 years ago

Well, I just tried it on my new Redmine 1.1 system, and it failed.

It failed to patch app/views/issues/_changesets.rhtml, and that results in an 'internal error' when trying to view a project's settings.

I patched by going to the redmine directory and running 'patch -p1 < ../multi-repo.patch'. Any suggestions? Is this not ready for RM 1.1?

Actions #73

Updated by Robert Gruendler about 13 years ago

i'd recommend to use the github fork until this feature is implemented, if possible. this fork implements the patch and i maintain it and merge all changes from the official github repository in there. however, i've attached an updated patch, which should work for 1.1.

Actions #74

Updated by Andy Bolstridge about 13 years ago

Robert Gruendler wrote:

i'd recommend to use the github fork until this feature is implemented, if possible. this fork implements the patch and i maintain it and merge all changes from the official github repository in there. however, i've attached an updated patch, which should work for 1.1.

Sorry, it still doesn't work. I tried with the patch and with the branch from your git repo (it's a right pain to download just one branch from git! go back to svn :) ) and I still get the error. FYI the patch still has the _changesets.rhtml error in it.

So, what else do I have to do besides overwrite my files with the patched ones and restart (httpd via passenger in my case).

Here's the error from the production.log:

ActionView::TemplateError (undefined method `name' for #<Repository::Subversion:0xb64b5da0

) on line #11 of app/views/projects/settings/_repository.rhtml:

8:
9: <div class="box tabular">
10: <p><%= label_tag('repository_scm', l(:label_scm)) ><= scm_select_tag(r, rid) ></p>
11: <
= repository_field_tags(f, r) if r %>
12: </div>
13:
14: <div class="contextual">

lib/tabular_form_builder.rb:35:in `text_field'
...

I am using the 1.1.0 version of RM, checked ut of SVN using the tags/1.1.0 branch (rev 4707). I assume this is the same one that built the 1.1.0 release (should be, but sometimes you never know!)

Actions #75

Updated by Andy Bolstridge about 13 years ago

Of course, I am an idiot for not migrating the DB too.

However, after restarting everything, the repository links on the project settings take an impossible amount of time to return (it hasn't yet, and right now I'm unconvinced it will)

I'll leave it spinning overnight, is there any way I can see what it's trying to do?

Actions #76

Updated by Robert Gruendler about 13 years ago

you could try to start redmine via the webrick server:

ruby script/server webrick -e production

and browse to http://yourredmine.instance.com:3000. You'll see the rails log entries in the console when using redmine.

Actions #77

Updated by Andy Bolstridge about 13 years ago

Thankyou. I think I have determined the error.

I created a new repository link in the project's settings - that works nicely.
then I browsed the project's repository page and all worked. I had 2 links at the top of the page to select which to use.

However, as I had only created a new one, the old link was the original, so it didn't have a name corresponding to it. I went to the settings, deleted that repository, and created a new one with the old path in it so I'd have 2 links at the top of the repo page with descriptiove names.

This is when it hangs.

Webrick shows the following (mangled hostnames, etc):

Processing RepositoriesController#edit (for <ip> at 2011-01-14 16:06:06) [POST]
  Parameters: {"commit"=>"Create", "rid"=>"1", "repository"=>{"name"=>"version 1.4", "url"=>"http://<hostname>/svn/<path>", "password"=>"[FILTERED]", "login"=>"admin"}, "action"=>"edit", "authenticity_token"=>"<blah>", "id"=>"uklv", "controller"=>"repositories", "repository_scm"=>"Subversion"}
Completed in 223ms (View: 148, DB: 8) | 200 OK [http://<webhost>/projects/uklv/repository/edit?rid=1]
svn: Unable to find repository location for 'http://<hostname>/svn/<path>' in revision 200
svn: Unable to find repository location for '<hostname>/svn/<path>' in revision 400

and so on, up to 'Unable to find repository location .. in revision 3800. I don't know why it stops there instead of continuing to the end of the revision history, or even to revision 311743 where it was created from a branch.

I have 320,000 revisions in this repo. The path to the repo is correct (I cut and pasted from my tortoise properties).

I should say that webrick has completely hung at this point - stopping the browser and trying different links has no effect, so I guess somethings died internally after retrying and logging those 20 times.

I also couldn't stop webrick using ctrl+c, I had to open a new terminal and kill it (it reported 'svn: Write error: Broken pipe')

so.. is this a new bug in the patch code, or an assumption about the repository size that's failing when I try to use my big one, or some particularly inefficient code (I see it creating many svn processes one after the other), or is there some niggle when the old repo link is deleted? I have cleared the cache (rake tmp:cache:clear) but that didn't work.

Note: I tried again, this time I just deleted the original repo link. Same error.
I also reset the entire repo settings, started again - same error :(

Actions #78

Updated by Andy Bolstridge about 13 years ago

  • Assignee set to Jean-Philippe Lang
  • % Done changed from 0 to 80

running it in debug shows a lot more information.

It appears this patch works well, assuming you set the 'autofetch_commits' setting to off, it won't trawl your repo looking for changesets, 200 at a time. I think the crashing problem was simply that the 'svn log' command would return nothing (ie fail) occasionally as redmine tried too many svn log commands too quickly. In the debugger, this results in an exception, in webrick this just hangs.


There are some outstanding niggles:
  • The links at the top of the repositories page should be bigger and bolder, maybe highlighted as buttons rather than just links.
  • The repository links could be matched with versions, as I think half the people using this need to show a single project with multiple releases, where each release is a different repository path (ie linked to a /tags directory - for example redmine.org has version 1.1.0 listed, that could have a link to /tags/1.1.0)

So anyway, after some testing, it does appear that this patch is a good 'un. How do we get it into the next release, as then some plugins can be upgrades (code review plugin doesn't work well with this, for example)

Actions #79

Updated by Toshi MARUYAMA about 13 years ago

This is a patch to fix broken revision link.
Target git revision is https://github.com/pulse00/redmine/commit/83fae10224d087b80dde0d82d13e68410a6ebeb3 .

Actions #80

Updated by Toshi MARUYAMA about 13 years ago

Github fork lost #5328 feature.

Actions #81

Updated by Toshi MARUYAMA about 13 years ago

  • File svn-shema-check.png added

Original Redmine checks Subversion schema (ex. file://, svn://).
Github fork lost this feature.

Actions #82

Updated by Toshi MARUYAMA about 13 years ago

  • File deleted (svn-shema-check.png)
Actions #83

Updated by Toshi MARUYAMA about 13 years ago

Sorry, attachment file in note 81 has typo.
I fixed and re-attach.

Actions #84

Updated by Robert Gruendler about 13 years ago

current trunk from edavis has been merged right now into the github fork. patch will follow when i have more time.

Actions #85

Updated by Andy Bolstridge about 13 years ago

I've been looking through the patch (partly to learn ruby, so forgive any comments where I'm just plain wrong - but do tell me!) and I have a few comments.

Each repository has an id associated with it, and the repository_controller selects which repo to use depending on a parameter that is passed in on the url. This should always set the Jack Zheng instance variable, but - some links (especially those that render the page rather than link to a new one) tend to reset the repository id.

so I'm beginning to question the validity of this approach. Should rid be set as another instance variable or symbol and set by the calling function? For example, the initial link from 'repositories' menu does not specify which one to use (so it defaults to 0) but that means the rid param is not set so items like the repo name is not shown unless you click the link to one (at the top).

Similarly, the 'view all revisions' link shows all revs for the first repo, not the desired one as the rid param can't be passed in properly.

I've started updating the code to use an instance variable that is set in the find_repository method and use that throughout the rest of the class. I'll let you know
how it goes.

Actions #86

Updated by Larry Cai almost 13 years ago

Tim Henigan wrote:

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

+1, any plan to coming release

Actions #87

Updated by William Baum almost 13 years ago

Robert, would it be possible for you to merge the 1.1-stable branch into a branch of your fork, perhaps at the 1.1.1 or 1.1.2 release points? And/or perhaps a couple comments about how to best go about doing that?

I did take a shot at it, but I'm new to git, and my merge attempt made rather a mess.

Actions #88

Updated by Louis Simons almost 13 years ago

+1, in the same bin a Tim Henigan and Larry Cai

Actions #89

Updated by Joan Ginard over 12 years ago

+1

Actions #90

Updated by Mike Dubman over 12 years ago

+1

Actions #91

Updated by Artur Wasilewski over 12 years ago

+1

Actions #92

Updated by Artur Wasilewski over 12 years ago

Which patch works fine with current stable redmine release (1.2.11) ? Does any?

Actions #93

Updated by W Lao over 12 years ago

When can this feature be included in the official release?
The roadmap doesn't include this information.

Actions #94

Updated by Gilles Cornu over 12 years ago

+1

Actions #95

Updated by Don Doffe over 12 years ago

Would love to have multiple SCM support. It is the only reason we are going to keep Trac in place for a while (web based access to support ppl).

Actions #96

Updated by Carsten Nielsen over 12 years ago

+1

Actions #97

Updated by Jun Huang over 12 years ago

+1

Actions #98

Updated by Guillaume Chéramy over 12 years ago

  • Assignee deleted (Jean-Philippe Lang)

hello,

+1 for this features

Where to get the latest patch ? The pluse00 git repos seems not to work

Sincerely

Actions #99

Updated by Kaspars Sprogis over 12 years ago

+1
Really interested in this feature too. Any working patches, anyone?
Thanks

Actions #100

Updated by Anatol Bollinger over 12 years ago

+1

One team, one project, two scm archives.
Cheers,
Anatol

Actions #101

Updated by Jean-Philippe Lang over 12 years ago

  • Assignee set to Jean-Philippe Lang
  • Target version set to 1.4.0
  • % Done changed from 80 to 0
Actions #102

Updated by Colin Mollenhour over 12 years ago

While this ticket previously had my vote, I now prefer the solution proposed in #9703 since it allows for even more flexibility. When you have projects and sub-projects, one problem is that commits in a repo that reference a ticket in a sibling project don't get related. The solution from #9703 would solve this by allowing you to associate each repository with each project, or more likely each repository with the parent (assuming all children inherit relations in commits from the parent).

Actions #103

Updated by Jean-Philippe Lang over 12 years ago

#779 is needed by many people and it doesn't mean that some kind of repository sharing across projects won't be added later. I think this is the first step in this direction. Even if we don't have independent repositories, we could have a repository shared with all the subprojects and allow issue referencing between all of them.

Actions #104

Updated by Pedro Gutierrez over 12 years ago

--1

I'm more in favour of the solution proposed in #9703
I think that it is more flexible and would solve two problems and not only one:
  • multiple repositories per project
  • multiple projects per repository.
Actions #105

Updated by Ivan Cenov about 12 years ago

I've just tested the new features (r8648, r8649, r8650, r8651, r8652). Great addition to Redmine.
I would like to propose these visual enhancements:
  • The currently selected repository to be someway visually marked (bold, italic, or a check mark near the name)
  • The label "Main repository" to be replaced with the identifier of the repository and the fact that it is the main repository to be visually marked.

Also, when adding new repository, all the SCM are selectable in the drop-down list. It was not the case before. The SCMs that had been installed were in the drop-down list only.

Actions #106

Updated by Jean-Philippe Lang about 12 years ago

  • % Done changed from 0 to 80

I have made a few enhancements based on your feedback, thanks. The selected repository is highlighted in the sidebar and the "Main repository" label is replaced with the repository identifier (it is always at the top of the list so I don't know if a visual mark is required). I've also fixed the SCM drop-down list.

Magic links to revisions/files of other repositories other than the main one need to be implemented. Here is the proposed syntax:

  • Changeset: identifier:c6f4d0fd
  • Source: identifier:source:some/file
Actions #107

Updated by Ivan Cenov about 12 years ago

Jean-Philippe Lang wrote:

Magic links to revisions/files of other repositories other than the main one need to be implemented. Here is the proposed syntax:

  • Changeset: identifier:c6f4d0fd
  • Source: identifier:source:some/file

I have experience with Subversion only, and can propose the following:

Source: identifier:source:some/file[?r=nn][?p=nn]

examples:

myrepo:source:some/file.c           -- some/file.c from HEAD
myrepo:source:some/file.c?r=45      -- some/file.c from revision 45
myrepo:source:some/file.c?r=7?p=20  -- some/file.c from operative revision 7 and peg revision 20
myrepo:source:some/file.c?p=20      -- some/file.c from operative and peg revision 20

Actions #108

Updated by Etienne Massip about 12 years ago

Jean-Philippe Lang wrote:

Magic links to revisions/files of other repositories other than the main one need to be implemented. Here is the proposed syntax:

  • Changeset: identifier:c6f4d0fd
  • Source: identifier:source:some/file
What would you think of:
  • replacing Identifier property by a Name property (allowing spaces characters and such) because there are actually 2 Identifier columns (one for repo and one for the fetch account) and make it optional (or make it mandatory for the main repo too with a default i18ned value of "Main repo")
    Explanation: in the first place I didn't understand what the Identifier field was useful to, then I understood this was to display in the list, so why not a more friendly Name instead?
  • moving "Main repo" checkbox before the Name/Identifier field (no real reason)
  • using syntax like
    • Changeset: identifier:c6f4d0fd (same as proposed by JPL)
    • Source: source:identifier:some/file
      where identifier is the id of the repository?
Actions #109

Updated by Jean-Philippe Lang about 12 years ago

The repository identifier is used in urls (just like the project identifier):

/projects/foo/repository          => main repo (identifier is not required in the url to preserve existing urls)
/projects/foo/repository/other    => other repo

We could add a Name attribute for displaying in the sidebar.

The problem with myrepo:source:some/file.c is that it can be ambiguous with existing cross-project links like myproject:source:some/file.c if a repository has the same identifier as a project.

I'd prefer a syntax that would prevent ambiguousness like the following (just an example, the slash may not be the best option):

myrepo/source:some/file.c
myproject:myrepo/source:some/file.c

myrepo/r123
myproject:myrepo/r123

myrepo/commit:c6f4d0fd
myproject:myrepo/commit:c6f4d0fd
Actions #110

Updated by Jean-Philippe Lang about 12 years ago

Etienne Massip wrote:

  • moving "Main repo" checkbox before the Name/Identifier field (no real reason)

Indeed, changed in r8668.

Actions #111

Updated by Etienne Massip about 12 years ago

Jean-Philippe Lang wrote:

I'd prefer a syntax that would prevent ambiguousness like the following (just an example, the slash may not be the best option):

[...]

IMO, the ideal could have been to have the type of reference as first argument, e.g.:

source:myrepo:some/file.c
source:myproject:myrepo:some/file.c

myrepo:r123
myproject:myrepo:r123

(or weirder:
rmyrepo:123
rmyproject:myrepo:123)

commit:myrepo:c6f4d0fd
commit:myproject:myrepo:c6f4d0fd

I guess it's too late.

Actions #112

Updated by Nikunj Undhad about 12 years ago

  • Assignee changed from Jean-Philippe Lang to Felix Schäfer
Actions #113

Updated by Ivan Cenov about 12 years ago

When pressing 'View all revisions' link, the side bar disappears. It was not expected for me when I saw it for first time but now I am not sure if this is good or bad. Just mention it now...

Actions #114

Updated by Toshi MARUYAMA about 12 years ago

  • Assignee deleted (Felix Schäfer)
Actions #115

Updated by Terence Mill about 12 years ago

Will it be possile to grant different access rights role based to each repo?

Actions #116

Updated by John Kubiatowicz about 12 years ago

Just a curiosity question about repo identifiers. Any reason that they are not globally unique (and unique with respect to project IDs as well)? Then, (1) the identifier of the primary repo of a project could default to the project identifier, and (2) the set of all repos have unique names so that they can appear in a single, flat namespace (if desired).

I am just thinking about plugins such as redmine_git_hosting that manages repositories now (in <= 1.3 Redmine) in a way that can rely on the uniqueness of the project IDs to name the actual repositories. Constraining the identifiers to be unique across projects (and not the same as project-ids) would make such management simple.

Is the flexibility to have identifiers that are not-unique across projects a feature?

Actions #117

Updated by Andy Bolstridge about 12 years ago

One important aspect is the need to have the same repo specified in multiple projects. Think of several projects to all use the same 3rd party repo for example. each repo would be unique, both globally and with respect to a project, but a repo cannot then be tied to a single project, not unless we had non-unique repo ids (so you could specify the same repo many times, once for each project)

Actions #118

Updated by John Kubiatowicz about 12 years ago

Ah. So, it doesn't make sense for the same id to be used in different repos with different URLs? I guess your comment is a different take on what I said: every physical repository has a unique ID, possibly repeated in different projects? That seems like a use-case that might have a different "new repository" screen than currently offered: either pick an existing repo by name (in which case the URL is taken from an earlier definition) or define a new repo...

In this use-case, do you assume that the same physical repo would have different access control depending on which project it was accessed through? That seems a bit weird (and really messes up something like gitolite). That being said, however, gitolite supports per-branch permissions (for git). I guess it might make sense to have different branches of a physical repo be attached to different projects. Oy!

Also, what is the story with the primary repo (/without an identifier)? Is it considered project-specific and unique (not cross project)?

Actions #119

Updated by Andy Bolstridge about 12 years ago

I just wanted to make sure the most common use-case was catered for :)

I'm not sure about access-control. From my PoV, access control should be via the repository itself. I'm not sure if specifying different users even makes sense - you have a 'redmine' user and that's it. When it comes to reading the revision history, you want RM to have read access to the repo no matter what.

I guess some people will want access control for users viewing different repositories inside RM, but that is a project-based access control that has nothing to do with the repo link, you either allow a RM user to read the repo log comments that have been copied to the RM db, or you don't - RM itself still has to read the revision history or it just doesn't work.

Either way, I'm looking forward to this update, it's about time RM got some of the ancient feature requests resolved. I'm glad JPL is back on the case.

Actions #120

Updated by Ivan Cenov about 12 years ago

Andy Bolstridge wrote:

One important aspect is the need to have the same repo specified in multiple projects. Think of several projects to all use the same 3rd party repo for example. each repo would be unique, both globally and with respect to a project, but a repo cannot then be tied to a single project, not unless we had non-unique repo ids (so you could specify the same repo many times, once for each project)

There is another use case: many projects and every project has repositories 'software', 'electronics', 'mechanics', 'clients'. These repositories are different ones. Par example, project1.software and project2.software are not the same project.

Actions #121

Updated by Jean-Philippe Lang about 12 years ago

  • Assignee set to Jean-Philippe Lang

Repository identifiers do not need to be globally unique because each of them is tied to a single project. Please understand that this feature does not cover #9703 that would allow multiple projects to use the same repositories.

Actions #122

Updated by Etienne Massip about 12 years ago

Jean-Philippe Lang wrote:

Repository identifiers do not need to be globally unique because each of them is tied to a single project. Please understand that this feature does not cover #9703 that would allow multiple projects to use the same repositories.

New dumb question: why not let administrator manage repositories instead of project manager, that would make more sense since this is some kind of host machine level communication config, don't you think so?

Actions #123

Updated by William Baum about 12 years ago

Jean-Philippe Lang wrote:

Repository identifiers do not need to be globally unique because each of them is tied to a single project. Please understand that this feature does not cover #9703 that would allow multiple projects to use the same repositories.

While I can see the benefit of common names for repositories (code, db, requirements, tests, etc.), that would require using both the project and repository identifiers to access the repository. If a unique name was required, the existing url schemes, etc., could be used to access the repository, changesets, etc., just with the repository ID rather than the project ID. If non-unique names are used, this will break source/export links as well as some third party plugins and integrations (hudson, jenkins come to mind).

Also, it seems like non-unique names gets us farther from shared repositories (#9703) rather than closer to it.

Actions #124

Updated by John Kubiatowicz about 12 years ago

I would like to add another plugin that would be "broken" by non-unique IDs: redmine_git_hosting. (Perhaps "broken" is too strong a word, instead "complicated" is a better word.)

As it is, the uniqueness of the repository IDs is inherited from the uniqueness of the project IDs, and this plugin takes advantage of this property. The reason I first asked about uniqueness was that I am thinking of what would be involved in making this plugin work well with the new feature. One of my options was to "uniqueify" repository names by prepending the project-ID, but this has its own complications.

Actions #125

Updated by Brice Beaumesnil about 12 years ago

If it's possible to add a name to each Repository and show this name on Activity's page (near sub-project name for example).

Thanks.

Actions #126

Updated by Jean-Philippe Lang about 12 years ago

  • Status changed from New to Closed

Brice Beaumesnil wrote:

If it's possible to add a name to each Repository and show this name on Activity's page (near sub-project name for example).

r9257 adds the repository identifier to the activity view.

Actions #127

Updated by Daniel Dehennin over 11 years ago

Hello,

I'm looking for a documentation to clone my sub git repository

Looking at r9256 I thought it would be http://<base redmine url>/git/<project>.<subrepository name> but it does not work.

Any hints?

Regards.

Actions #128

Updated by Ivan Cenov over 11 years ago

Daniel Dehennin wrote:

Hello,

I'm looking for a documentation to clone my sub git repository

Looking at r9256 I thought it would be http://<base redmine url>/git/<project>.<subrepository name> but it does not work.

Any hints?

Regards.

No, this is not the way and it does not work.
Create a bare repository in the file system that is visible by Redmine server. Then when configuring the repository in Redmine, set the path (the physical path in the file system) to this repository. This is different from what is done when configuring SVN repository -- SVN repos may be referred by URL. After you have done this, you should be able to see the repository in Redmine.

Actions #129

Updated by Daniel Dehennin over 11 years ago

Ivan Cenov wrote:

No, this is not the way and it does not work.
Create a bare repository in the file system that is visible by Redmine server. Then when configuring the repository in Redmine, set the path (the physical path in the file system) to this repository. This is different from what is done when configuring SVN repository -- SVN repos may be referred by URL. After you have done this, you should be able to see the repository in Redmine.

I'm not sure that Apache::Authn::Redmine::access_handler works with multiple repository, the repository should be "clonable" anonymously but authentication is asked and fail :-/

Actions #130

Updated by Olivier Mehani almost 9 years ago

Daniel Dehennin wrote:

I'm not sure that Apache::Authn::Redmine::access_handler works with multiple repository, the repository should be "clonable" anonymously but authentication is asked and fail :-/

Yup, I just ran into this issue myself. Does this mean that it is not currently possible to authenticate to a repo which doesn't have exactly the name of the project?

Actions

Also available in: Atom PDF