Can Subversion Plus track moved issues

[Sean Evans]

Hi,

We're using Subversion Plus version 5.3.4 with JIRA 6.1.4 and we've noticed that after moving an issue to a different project the Subversion tab does not show changes made for the old project. E.g issue OLD-135 had some changes shown under the Subversion tab, then was moved to project NEW as issue NEW-7. Entering OLD-124 in the quick search box redirects to NEW-7, but the Subversion tab does not show any activity. We'd like to see the activity related to the old issue ID under the new issue.

Is there an option to allow this, or, if not, any plans to include it in the future?

[Pablo Beltran · Accepted solution]

Since the 5.5.0 version, you can access to the Subversion ALM internal database from your own plugin, so you could capture moved issue events and keep aligned the Subversion cache accordingly.

There is avaibale an example showing the amount of commits of each project in a tab.

[Sean Evans]

Just to round this off, am I correct to assume that there are currently no plans to include the required functionality in the 'Subversion ALM' plugin?

[Pablo Beltran]

You are right. This kind of functionality requiring users to modify JIRA along with Subversion in a synchronized way are not automatically supported. It means the plugin provides several ways to make changes by hand in an straighforward way through the database web console or allowing users to automate the changes by them selves throught the shared JDBC connection ;)

Please, keep in mind that if an issue/commit is changed in the index database, this change should also be performed on Subversion in order to persist along the time or you could lose the changes in the future...

[Pablo Beltran]

You are right. This kind of functionality requiring users to modify JIRA along with Subversion in a synchronized way are not automatically supported. It means the plugin provides several ways to make changes by hand in an straighforward way through the database web console or allowing users to automate the changes by them selves throught the shared JDBC connection ;)

Please, keep in mind that if an issue/commit is changed in the index database, this change should also be performed on Subversion in order to persist along the time or you could lose the changes in the future...

[Edited to move the answer under the right question]

[Pablo Beltran]

Subversion ALM (AKA Subversion Plus) supports it in a straighforward non-automatic way through the database web console.

Please, see this example (animated GIF) about how to start the console and modify the issues related to commits on the fly:

http://goo.gl/z3lmIk

Hope this helps.

[Sean Evans]

Thanks for the response.

I suspect this method will be too labour intensive and specialised (requiring admin privileges) for our purposes, and I guess we would also lose these manual updates if it is ever necessary to regenerate the index (e.g. as necessary for some upgrades). For these reasons we were hoping for an automated solution. Is this something that could be included in a future release?

[Pablo Beltran]

I suspect this method will be too labour intensive

It would depend on how much frecuently you move issues.

and specialised (requiring admin privileges)

No JIRA administration privileges are required in order to access to the web console. As you can access to the Subversion ALM remotely by using standard JDBC and SQL, you might want to write your own custom script in order to automate this process. For instance:

update_moved_issue.sh OLD-135 NEW-7

where update_moved_issue.sh would be an script connecting to the database to replace the OLD-135 issue key by the NEW-7.

Furthermore, in next release, the database connection will be exposed as a public component by the add-on. It means, everybody could develop his own JIRA plugin and get a connection for the Subversion ALM internal database, thus you could do it much more integrated with JIRA and contol who and how can do it accordingly your needs or even do it fully atomatic without any GUI. However, I would recommend you providing a GUI as for the same cost, you could also support fixing errors when developers type a wrong issue key in the commit message which is a very popular requirement too.

[Sean Evans]

I take your point about admin access not being required, but it's still definitely something that for speed and validation would be better automated. I think at the time that the issue is moved it would not necessarily occur to the person doing this to take the additional step to update the ALM database. Even if they do there's the possibility that they make a mistake and enter incorrect information. And there would still be a problem if the database has to be regenerated.

Is it possible that as part of the indexing process that a check for a moved issue is performed? If not then hopefully the next release will allow us to implement something along these lines.