Project

General

Profile

Forums » Help »

Overlapping Repositories / Projects

Added by Shaun Sutterfield about 14 years ago

Questions about Redmine and SVN:

When Redmine is reading the commit history for project A, and it sees a "Refs #1234", but issue #1234 is actually in project B, will it still setup the relationship (assuming project B has the repository module enabled)? Or does it ignore it?

If two projects in Redmine point to the same repository URL in SVN (or maybe one contains the other, i.e. is in a higher-level folder), what happens when Redmine reads the commit history? Will it end up with duplicate data, e.g. will Issue #1234 show a related commit twice, once for each time the commit history was read? Is there a difference if one project is made a sub-project of the other within Redmine? (does the relationship of parent/child projects within Redmine affect repositories at all?)

I'm worried about corrupting the data within Redmine. I've got a situation where I want to have a "master project" that has issues related to a software product as a whole and tracks issues that we don't want customers to see when they login to Redmine, and then there's the individual customer projects where customers can create and view issues related to their account. I enter all of my development comments to issues via SVN commit messages (via Visual Studio/Ankh). So far, we've just had the "customer projects" but I'm in the process of creating the "master project" in Redmine and wanted to know if I'm about to shoot myself in the foot as far as how Redmine talks to SVN... :-)

I know I can do a MySql backup of Redmine's data and just try it (in fact, I'm intending to)--but even if that appears to work, I don't know if there's some invisible glitch being caused in the data that will show up down the road..


Replies (2)

RE: Overlapping Repositories / Projects - Added by Shaun Sutterfield about 14 years ago

To share what I've discovered:

My first question was, if the repository for project A refers to an issue in project B, will it still setup the association between the Redmine issue and the SVN revision. In fact, it did, but it also caused a duplicate, so under "Associated Revisions" in project B's issue, the revision appears twice. It was easy to clean up, though...

I tried this:

Project A is the 'parent' project of project B (in Redmine). I went to B's repository settings and clicked on 'Delete' to clear out the settings. On that test issue where the revision showed twice, it now only shows once (I'm assuming from A's data)... nice and easy cleanup. If this is working the way I think, then I can work with this... it means I have to go to the parent project to see the Repository tab (and that's what I click on to make it update, I've tried the auto-fetching as a scheduled task and it just kills performance on the server), but there's no duplicate data and I can still refer and close issues via SVN commit messages. Not the ideal solution, but for what I'm wanting at the moment it will work.

This leaves me with another question, though. I'm wondering what security checks Redmine does when it reads the SVN repositories. Say someone else has a project in my Redmine, and it's linked to their SVN server. I have my own project (that they don't have access to), linked to my SVN server. If they are using the "closes" tag and they mistype an issue number in one of their commit messages and the number that was entered is one of the issues for MY project, will that close the issue in my project? That would kind of suck...

(I may be disabling the "closes" option anyways, because I've gotten into a bad habit of not going back and entering my time... and the project managers aren't really appreciating that fact... :-)

RE: Overlapping Repositories / Projects - Added by Felix Schäfer about 14 years ago

Redmine is built with the assumption that one repository is only tied to one project, nothing bad will happen if you have many projects sharing a same repository (or parts thereof), but you might get weird things, like the double Associated revisions you observed (each coming from the 2 projects you had the repository configured for). There will be no data creep or anything though other than the multiple Associated revisions, and as you have found out, this is easily fixable by just deleting the repository in one project (deleting a repository in a project deletes the redmine-cached commit logs and the associations between revisions and tickets, but you get all that back if you add the repository again).

Regarding the "cross-project" Associated revisions, this only works for projects of the same tree if I remember correctly, i.e. the issue links in the commit logs will only be parsed for issues in the same project-tree.

Regarding the performance of the cron changeset fetching: yes, it doesn't scale because it effectively walks through all repositories and asks them if they have something new, but you might be interested in #3667 in which I describe how to make redmine fetch the changes only for that repository in a post-commit hook (be aware that this works on only if the repos and the redmine are on the same server, though IIRC a special URL you can GET to make redmine fetch changesets for a given project has been added to redmine since).

    (1-2/2)