Migrating from the Atlassian Jira Subversion plugin

Owned by Pablo Beltran (Unlicensed)
Last updated: Aug 11, 2019
3 min read

Compatibility issues

Subversion ALM is not compatible with the Atlassian's plugin: the Atlassian's plugin must be uninstalled prior install Subversion ALM.


Subversion ALM is able to import the registered repositories by the Atlassian's plugin. Only basic configuration data is imported (Repository name, URL, user's credentials, etc). The repositories must be fully indexed again from the beginning once they have been imported. It could take more time because Subversion ALM caches much more data than the Atlassian's plugin.

Add the following parameter to the Subversion ALM's configuration page URL in order to see the import links:

importLinks = true

ROOT URLs

Subversion ALM supports ROOT URLs only!

All the URLs pointing to a subdirectory (branch in Subversion) will be converted to their root URLs and you see Unauthorized errors.

Provide the user's credentials (username & password) for a Subversion user with read-only privileges from the root repository.

If you are importing two branches of the same repository, only one will be converted to the root URL and imported. Next will fail as only one URL per repository is allowed.


Reverting the migration

Since the Atlassian's Jira Subversion plugin's configuration and cached data remains on JIRA after they have been migrated to Subversion ALM, it is possible reverting the installation at any moment by following the reverse way: uninstall Subversion ALM and /reinstall the Atlassian's JIRA Subversion plugin.

Of course, the Subversion repositories registered directly on Subversion ALM will not be available on the Atlassian's JIRA Subversion plugin.


Major differences

Both work essentially in a similar way since they scan registered repositories and parse commit messages to find out related issues and display them from Jira Server and Data Center.

However, they differ a lot for the rest of the features.

The Atlassian's plugin only fetches commits from Subversion, therefore is very fast indexing repositories compared to Subversion ALM which also fetches all the items (files and directories) in each commit.

The Atlassian's plugin stores very few data in Lucene: only the issues related to some commit, whereas Subversion ALM also stores the full history of each repository on the Jira database.

Therefore Atlassian's plugin is capable only to show commits related to issues from Jira Issues and Projects and they are linked to an external Subversion web client tool like ViewVC, etc. On the other hand, Subversion ALM does that too, but commits are also shown from the Jira Software Agile board details views, it provides a built-in full-featured web tool to explore Subversion repositories (formerly Siemens' Polarion), so no third-party server is required. and it also capable to take advantage of all Subversion data stored in Jira to display commit calendars, commit graphs, native JQLs integrated with Subversion data.

The SQL+JQL Driver is packed within Subversion ALM for enterprise reporting, so it is possible to create any kind of basic or advanced custom report (via Eclipse BIRT), to relate commits and items with the rest of Jira entities (versions, components, Agile boards, Sprints, etc) running in the context of the calling user.

And one of the most important: Subversion ALM is not discontinued. It is very well supported and with regular releases.

Due to the richness of features supported by Subversion ALM, it is closer to FisheEye to integrate Subversion with Jira than to the discontinued Atlassian's plugin.


Since Subversion ALM stores in the Jira a lot of Subversion data, it is important to perform a database capacity planning before migrating from the Atlassian's plugin