Project

General

Profile

Actions

Feature #286

closed

SVN revision pseudo-automatically linked to issue

Added by Jonathan Dance over 17 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

It would be nice to have a post-commit script that can be installed that will inform RedMine of a new commit along with
its log message. In this log message, one could put a bug number, e.g.:

Bug ID: 12345

This would indicate to RedMine that this revision should link to that particular bug/issue. This would appear near the
top of an issue with a list of revisions (and files affected in that revision) that were linked to that issue. You would
be able to click on each file in the revision to view the diff for that file+revision.

This is a feature of Fogbugz that I think is pretty nifty... it really makes SVN integration very cool and useful. See
these links (the last one has a screenshot of their UI):

http://www.fogcreek.com/FogBugz/docs/50/Articles/SourceControl/SubversionIntegrationScri.html
http://www.fogcreek.com/FogBUGZ/help/Subversionscripts.html
http://www.fogcreek.com/FogBugz/docs/50/Articles/SourceControl/TortoiseSVN.html

Actions #1

Updated by Alessio Spadaro over 17 years ago

I already use a similar feature with trac.
When a commit message contains a term like "close",
"fix", "ref", "see" with a ticket
(issue in redMine) number (or several), the relevant tickets
are updated in a sensible way.
e.g. "closes 141" closes issue 141, "ref 233"
put a comment on issue 233, etc...
Usually comments reports the full svn comment.
Trac's post-commit hook is available
at http://trac.edgewall.org/browser/trunk/contrib/trac-post-commi
t-hook

Actions #2

Updated by Jonathan Dance over 17 years ago

Sounds even better, and we have BSD-licensed code we can base
it off of. I
might look at tackling this and submitting a patch at some point,
unless
someone else beats me to it. :)

Actions #3

Updated by Alessio Spadaro over 17 years ago

Well, the main problem i see is that they use trac directly as
in the current version trac and the repository trac is bound
to must reside on the same host.
As we can refer to remote repository, we must consider a remote
interface with all the security concerns it brings.
Probably using ActionWebService to model a sensible interface
to expose (maybe to other.. for example to continuous build systems,
which will be my next proposal) the relevant operations and then
build the hook using this will be the best thing (maybe Jean-Philippe
has already planned some kind of remote interface).
Maybe i'll have some time during the we to look into this and,
of course, i'll be glad to help with the implementation

Actions #4

Updated by Jonathan Dance over 17 years ago

I would not recommend using AWS - it is overly complicated and
generally
annoying to work with. I would look at either using simple GET/POST
methods with form-style encoding, or creating a REST-style
interface.

As far as security, you would probably just generate an "API
key" to give to
the post-commit script. This would be one of the parameters you
would pass
to the API.

Lastly, you would probably need to deal with matching Subversion
usernames
to RedMine users if you want to accurately say which user did
what. This is
probably something you would have to add to the RedMine user
form.

Actions #5

Updated by Alessio Spadaro over 17 years ago

Good advice, i write AWS, but only as an example as i never use
it directly. Maybe the REST interface is the best one.

As far as security, i'll consider to allow only some specific
hosts (e.g. only the local network for a internet-exposed instance)
, use a security key or both as a minimum set of features.

Thinking about users, i think that defining multiple external
services and defining user mapping on these wuold be better than
hooking into the user form (and "polluting" it).

Actions #6

Updated by Nick Read over 17 years ago

Just adding my 2 cents...

It would be preferable to stay away from Subversion specific
features such as post-commit hooks as a permanent solution.
There are already another feature request asking for CVS support,
but with the rise in usage and popularity of distributed SCMs
(eg, GIT, SVK, Darcs), it can't be guaranteed that features like
post-commit hooks will be available.

Trac scans the repository logs every X minutes, and imports the
changeset details into it's own database as a cache. I would
prefer if redMine was doing this too, as it would allow us to
interrogate the changeset comments for issue numbers and link
it to the issue(s). Jira has an SVN plugin that does just this,
except that it does not cache the changesets in it's own database
unless the changeset refers to an issue.

Anyway, post-commit hooks are something that could be done now
without any changes to redMine.

Actions #7

Updated by Jean-Philippe Lang over 17 years ago

SVN commits are now stored in the database. See:
http://rubyforge.org/tracker/index.php?func=detail&aid=9402%a
mp;group_id=1850&atid=7163

With a simple cron task, redMine can now scan repositories for
new commits.

Actions #8

Updated by Jean-Philippe Lang over 17 years ago

Feature added.

More details can be found here:
http://rubyforge.org/forum/forum.php?thread_id=13594&forum_id
=7504

Actions #9

Updated by Todd Nine almost 15 years ago

Just adding my 2 cents. I personally feed that Redmine is quite superior to Jira and Bugzilla. However, a lot of software, such as Teamcity, Cruise Control all support integration with Bugzilla. Given that the Bugzilla RPC api is widely accepted, are there any plans to implement a Buzilla RPC compliant adapter into Redmine? I think this would help with acceptance of redmine into enterprise operations such as ours.

Thanks,
Todd

Actions #10

Updated by Todd Nine almost 15 years ago

Sorry, delete these 2 notes, I added it to the wrong issue. See #4798

Actions

Also available in: Atom PDF