Subversion plugin doesn't link commits to issues

[Gunnlaugur Jonsson]

I've installed the subversion plugin but have a problem getting it to read the repositories I have added. The plugin gets a connection to the repositories, reports the correct revision in all the repositories but never seems to scan/index them.

The Indexer process is configured to run every 60 minutes but as far as I can see it hasn't done anything yet. I've tried clicking on "Force the indexer process to run now" but I can't see that it does anything.

I'm probably missing something but the documentation is vague on several points so I don't really know what that could be.

[Gunnlaugur Jonsson · Accepted solution]

Just so I can close this, here's a summary: Nothing I tried managed to get the plugin to scan the repositories so I've switched to Atlassian's own plugin for the time being. Once I have time I'll try again to figure out what is causing this.

[Norman Abramovitz]

I am assuming you had a subversion version 1 plugin previously installed and not the newer version 2 installed subversion plugin. I had a similar issue as well before trying to install subversion plus. In my case I did not install subversion plus right away, so I had errors showing in the logs.

I am remembering the steps I went through, so I do not have all the details. I got subversion plus to work by:

1) I could not remove the service entry for the subversion plugin (version 1) because there was no delete button showing.
2) Shutdown Jira
3) Removed the subversion files that I copied
4) Restarted Jira
5) Saw errors in the logs and searched for those error messages and found the information about rebuilding install directory.
6) Shutdown Jira
7) Followed the directions for rebuilding the install directory
8) Restarted Jira
9) Still had errors in the logs but they were related to trying to start the subversion service. The subversion entry was grayed when I looked at the services screen.
10) Shutdown Jira
11) I found the table where the service entry was stored and deleted that record.
12) Restarted Jira
13) Now my logs looked clean for a system startup.
14) Install subversion plus
15) Configured subversion plus by using the previous subversion cache

[Kinto Soft]

Did you try by re-starting the plugin? That should close all the database connections and create a new database connection pool again. Then refresh the repository list page to see any indexation progress. If the above does not work, then click on the Force... link. And if does not work yet, enable the plug-in logs by adding the "pbeltranl" the "svnwebclient" and "org.polarion" packages on JIRA (at the INFO level). Can you browse on Subversion? http[s]://<jira_server:port contextpath="">/plugins/servlet/svnwebclient/directoryContent.jsp

[Gunnlaugur Jonsson]

Hi

Yes, I can browse the subversion repositories through Jira without any problems.

Restarting the plugin gave me some hints on what may be wrong. I got these two messages:

"The scheduled interval for the Indexation process might have lost its value."
"The database configuration cannot be read because the lazy initialization of the Active Objects"

Clicking on "Initialize Active Objects" gives this error:

Database Cache
Error
"The database is read only [90097-171]"

Where do I enable the plugin logs? In the startup scripts or somewhere in Jira?

[Kinto Soft]

Did you install an earlier version (2.0.0 - 2.0.5) on MySQL?

Regarding the logs: Administrator > System > Troubleshooting and Support > Logging and Profiling > Default loggers > Configure

[Gunnlaugur Jonsson]

No, clean install with PostgreSQL on a CentOS 6.1 (upgraded to 6.4).

I disabled the plugin and now I'm having some other strange issues, trying to access the Administrator->System menu gives me a 404 error:

Not Found (404)
/secure/admin/jira/views/applicationproperties.jsp
Could not find what you were looking for. Maybe you should raise an issue.
Go to JIRA home

Now I can only access some parts of Administration but System is completely out and User Management crashes with "java.lang.IllegalStateException: No output folder". Rebooting and restarting Jira has no effect.

[Kinto Soft]

If JIRA is not working fine itself, it could impact on the Subversion plug-in too. I would recommend to get an stable JIRA instance and install the plug-in again.

[Gunnlaugur Jonsson]

The problem is that Jira has been working just fine until I started trying to get the subversion plugin to work. I had a similar problem with the old (v.1) manually installed Subversion plugin from Atlassian - I ended up having to remove and reinstall Jira. Looks like I'm back in that situation now.

[gullij]

Got help from Atlassian with Jira, deleting everything from the {jira_install}/work directory got things working again.

Still couldn't get the Subversion Plus plugin to scan any of my repositories so I switched to Atlassian's own that scanned and linked immediately. Not as complete as Subversion Plus but will have to do until I can find out why the index scanner doesn't work.

[Gunnlaugur Jonsson]

That previous comment was mine, was logged in with the wrong account.

[Kinto Soft]

Please, keep in mind that the Atlassian JIRA Subversion plug-in and Subversion Plus are not compatible, hence you have to completely remove the Atlassian's plugin before install Subversion Plus.

For example, both plug-ins share the same service key for the indexing process, hence only one of then can be activated by JIRA. It could be the reason because the index process does not run for Plus.

[Gunnlaugur Jonsson]

I'll keep that in mind when I test Subversion Plus again. I hadn't installed the Atlassian plugin until after I removed SPlus so that wasn't causing the problems.

I hope to try Subversion Plus again soon, just don't have time to get into that right now.

[Gunnlaugur Jonsson]

A little more information, when I remove one of the repositories and add that again I get this error:

Error
Database may be already in use: "Lock file exists: /var/atlassian/application-data/jira/caches/indexes/plugins/docminer-subversion-revisions_h2/index.lock.db". Possible solutions: close all other connection(s); use the server mode [90020-171]

I think this has something to do with the optional daemon listener that I have turned off but I'm not sure.