We have a SVN repository that contains resources for many projects. However, in the jira-client.pl script there is a $projectKey variable which is passed into the "commitacc.acceptCommit" XML/RPC call. This seems to imply that the plugin can only be used with repositories that relate to only one project.
Looking at the source for EvaluateService (1), it seems it might be possible to change this to support either a list of projects (comma separated) or to search all projects (if no project is specified at all).
We have a SVN repository that contains resources for many projects. However, in the jira-client.pl script there is a $projectKey variable which is passed into the "commitacc.acceptCommit" XML/RPC call. This seems to imply that the plugin can only be used with repositories that relate to only one project.
Looking at the source for EvaluateService (1), it seems it might be possible to change this to support either a list of projects (comma separated) or to search all projects (if no project is specified at all).
(1) http://svn.atlassian.com/svn/public/contrib/jira/jira-commitacceptance-plugin/trunk/src/java/com/atlassian/jira/ext/commitacceptance/server/evaluator/EvaluateService.java
Should there be AND or OR relationship?
Comment from Kevin Menard:
I'd say it should be an "OR" relationship. The crux of the matter is that it's fairly customary to have some sort of SVN root from which other projects are created. It can make configuration easier for a lot of tools. For example, ViewVC rewards users for having a common root, as does Subversion itself (see: SVNParentPath). In this case, we could have something like the following:
On the filesystem, these may map to the repository at:
/svnroot/root/
"www" and "some_swing_app" have nothing to do with each other. Without a doubt, they'll each have their own projects in JIRA. However, since the repository is the common "root", the pre-commit hook needs to be able to handle both.
Ferenc Kiss added a comment - 17/Jul/07 01:14 AM Should there be AND or OR relationship?
Comment from Kevin Menard:
I'd say it should be an "OR" relationship. The crux of the matter is that it's fairly customary to have some sort of SVN root from which other projects are created. It can make configuration easier for a lot of tools. For example, ViewVC rewards users for having a common root, as does Subversion itself (see: SVNParentPath). In this case, we could have something like the following:
http://localhost/svn/root/wwwhttp://localhost/svn/root/some_swing_app
On the filesystem, these may map to the repository at:
/svnroot/root/
"www" and "some_swing_app" have nothing to do with each other. Without a doubt, they'll each have their own projects in JIRA. However, since the repository is the common "root", the pre-commit hook needs to be able to handle both.
The commit hook script could have easily have a dictionary of regex/project pairs which determine which project is used in the script - or even IF the script should run.
Mark Derricutt added a comment - 20/Aug/07 06:55 PM The commit hook script could have easily have a dictionary of regex/project pairs which determine which project is used in the script - or even IF the script should run.
New Feature
Resolved
Major
Support multiple projects per repository (multiple project keys in one hook script)
Comment from Kevin Menard:
I'd say it should be an "OR" relationship. The crux of the matter is that it's fairly customary to have some sort of SVN root from which other projects are created. It can make configuration easier for a lot of tools. For example, ViewVC rewards users for having a common root, as does Subversion itself (see: SVNParentPath). In this case, we could have something like the following:
http://localhost/svn/root/www
http://localhost/svn/root/some_swing_app
On the filesystem, these may map to the repository at:
/svnroot/root/
"www" and "some_swing_app" have nothing to do with each other. Without a doubt, they'll each have their own projects in JIRA. However, since the repository is the common "root", the pre-commit hook needs to be able to handle both.