Subversion ALM - Repository Browser does not work

[ARM Ltd. (old account)]

Hi

We are trying to evaluate the Subversion ALM PlugIn instead of Jira Subversion PlugIn.

There are some questions that we would like to clarify:

1. Is it necessary to Uninstall Jira Subversion Plugin when installing Subversion ALM one?
2. Does the Subversion ALM migrates data from Jira subversion Configuration or it is necessary to add all repositories again?
3. We are using WebSVN Subversion frontend which uses Apache Auth Basic Authentication via LDAP and seems the Subversion ALM Plugin integrated SVN Web Client does not support that kind of authentication and fails to login to repostory for browsing. At the same time seems Repository Reindexing is working properly.

Regards,

Areg

[Pablo Beltran · Accepted solution]

I have noticed that the plugin looses all the configuration when the Server ID is changed.

You can reuse databases by changing the SERVER ID. For example, you have an old instance binded to the SERVER_A and you want to reuse it from the SERVER_B. Then,

• Install Subversion ALM on the SERVER_B.
• Disable the plugin
• Replace the database file
• Enable the plugin
• Open the database web console
• Drop the current schema: DROP SCHEMA "CLIENT_SERVER_ID_B" (notice thah the server Id name uses underscore "_" rather than dashes "-" and is prefixed with "CLIENT_")
• Rename the old schema name by running: ALTER SCHEMA "SERVERID_A" RENAME TO "SERVER_ID_B"
• Re-start the add-on (disable + enable)

Could you please advise any way to backup the configured repositories so it will be possible to restore data after QA instance creation?

There are two approaches depending on what you need/want to.

In order to backup the full database, you can follow these H2 backup/restore instructions. To export few tables you might want to use CSV.

Also another question together with this - what is the best options to Backup/Restore configuration and the PlugIn data?

That depends on a lot of parameters. In most cases I would say this is not necessary because the add-on can be installed and configured easily and quickly. So you can be ready again within few minutes from the scratch.

For this cases, no-backups or ocasional backups by using the GUI provided by the web console would be enought (From the login Web console > Click on the "tools" link at the top of the page > Backup > fill out the required data -> This will create a backup on the JIRA server)

Unless you have many repositories (so it is hard to register them one by one), huge repositories (so indexing them could take some hours/days) or Subversion ALM is critical (so each second have to be taken in consideration) you might want to automate this process. In this case, you can write your own plugin, using the JIRA scheduling process and run a BACKUP command periodically). In order to restore it, I would say the the GUI provided by the web console is the best choice (tools > restore).

Keep in mind that the indexing process is quite robust as it is 100% ACID transactional (it relies on the H2 transactions). I mean if you lose 3 hours since the latest backup, there would not be much problems as the indexing process would detect the latest parsed commits and would go on from there without any problem (for all the registered repositories) in the meanwhile, the bundled Polarion web client for Subversion would work as normal because it access to Subversion directly. Only the calendars, the commit graphs and the JQL functions could be affected until all the repositories be fully indexed again.

Hope this helps.

[ARM Ltd. (old account)]

Hi Team

Thank you very much for the help.

This completely solved my problems.

Regards,

Areg

[Pablo Beltran]

Great!

do not forget please review it as it might encourage other users to give it a chance :)

Thanks

[Pablo Beltran]

Subverion Plus was renamed to Subversion ALM.

You can read more and install it from the Marketplace:

https://marketplace.atlassian.com/plugins/com.kintosoft.jira.subversion-plus

[Deleted user]

Could anyone add the correct flag to it? I searched for the flag denoted by the link https://answers.atlassian.com/tags/addon-com.kintosoft.jira.subversion-plus, and could not find it.

[ARM Ltd. (old account)]

Hi Team

I have another question about the PlugIn.

I am going to install it on production system and in order to use it I need to export all configured repositories in existing subversion PlugIn and then manually configure them in your one.

Also we have a secondary QA instances of Jira which are created as a copy of production with some changes and also the server ID changed so there will be no conflicts when we are creating the Application links and other stuff.

I have noticed that the plugin looses all the configuration when the Server ID is changed.

Could you please advise any way to backup the configured repositories so it will be possible to restore data after QA instance creation?

Also another question together with this - what is the best options to Backup/Restore configuration and the PlugIn data?

Regards,

Areg

[ARM Ltd. (old account)]

Hi

It did not make a difference but in any case I am happy that people could not login via different account.

Regards,

Areg

[Pablo Beltran]

Please, try by deleting your cookies (or the JSESSIONID at least). Does it resolves the problem?

[ARM Ltd. (old account)]

Hi Team

Thanks for response.

I have tried to logout from SVN Browser and login with the different user but all the time I was logged in to the SVN using my current logged in credentials and SVN Browser completely ignored any of details I have tiped as I can type eve non existing username password to the login prompt and it passes the authentication as current logged in user.

This can be the part that Jira has integrated Apache frontend with the AJP Proxy and LDAP Authentication Integration as the Subversion Server Web Frontend.

Regards,

Areg

[Pablo Beltran]

Does this mean that the plugin is using current session details and completely ignores the typed username and password?

No, for non empty credentials.

You might want to do the following test:

1. From the same browser, open two pages and click on the Subversion menu at the top of JIRA (if you are logged in, please click on the logout link at the top right). At this time, you should see two login screens.

2. Page 1: log in as user A (user A has a valid session)

3. Page 2: log in as user B (as both pages share the same cookie/session -> session of user B repalces the user A session).

4. Page 1: perform some action on Subversion from the browser (you might create a folder, for instance) -> the author of the commit is User B.

The example above would desmorate how if you have a vallid session (A) and login with a different user (B), the Subversion web client takes in consideration the new typed credentials (B) by closing the old session (A) and creating a new one (B) rather than ignoring the credentials (B) if a valid session (A) is present.

Hope this helps.

[ARM Ltd. (old account)]

Hi

Something strange I have noticed today.

The Instance of Jira which I was testing the PlugIn was connected to completely different LDAP server on which we have passwords changed for the testing purposes.

I have tried to install the PlugIn on other two instances which are connected to the correct LDAP server and I was able to browse the repository which is failing on first instance even without typing username and password.

Does this mean that the plugin is using current session details and completely ignores the typed username and password?

Could you please clarify this?

Regards,

Areg

[Pablo Beltran]

At the same time seems Repository Reindexing is working properly.

The indexing process and the Polarion web client for Subversion use the same Java libray (SVNKit) in order to access Subversion. It means that if the indexing process can authenticate againts Subversion then there is not any problem in using LDAP and therefore the bundled Polarion web client should also be able to authenticate without problems.

Well, it could not work due some bug, but I've looked into the code causing this error and a simple error as a typo in the password might cause this.

Please, might you try log in Subversion by using a different user?

If it will be possible to disable it so the links will be pointing to the SVN server as in original Subversion PlugIn it will be useful.

If you are not interested in the features provided by the customized Polarion web client for Subversion then you might want to run both plugins at the same time and use the Atlassian's plugin in the front end and Subversion ALM in the background.

All the GUI components provided by Subversion ALM (the issue and project tabs as well as the Subversion menu) can be disabled from JIRA to avoid duplicities, so your uers would see no changes.

With the configuration above you would get support to run JQL queries against Subversion and you would miss sorting and pagination of commits.

[ARM Ltd. (old account)]

Hi

The svn servers are located on physical servers with the names like svna, svnb, svnc, svnd

The svn is a CNAME to one of the active servers while the others are backups.

All the hosts are successfully resolved by DNS.

I am not sure if I need to put it to /etc/hosts as repository successfully reindexed and there are the links to the Jira Issues.

It is only the SVN browser is not working as there are no configuration for it ...

If it will be possible to disable it so the links will be pointing to the SVN server as in original Subversion PlugIn it will be useful.

Regards,

Areg

[Pablo Beltran]

[svnwebclient.authorization.impl.CredentialsManager] It's not allowed to enter, your credentials: username: user, url: http://svn.company.com/svn/it/dev/

This error was reported in the Polarion's Web Client for Subversion forum a long time ago:

http://forums.polarion.com/viewtopic.php?t=3142

Does it resolve your problem?

In this case I would like to check the possibility to disable the integrated Repsitory Browser

Since the 2.x version, it is not possible to replace the bundled Subversion Web Client.

Do you have any bug reporting place to report this rather than Atlassian Answers?

Not at this moment :(

[ARM Ltd. (old account)]

Hi Team

Thanks for quick response.

I finally got the error message:

2014-01-31 16:16:08,361 ajp-bio-127.0.0.1-9160-exec-6 DEBUG user 976x109938x1 13esied 10.2.131.103 /plugins/servlet/svnwebclient/directoryContent.jsp [svnwebclient.authorization.impl.CredentialsManager] It's not allowed to enter, your credentials:  username: user, url: http://svn.company.com/svn/it/dev/

Seems the problem is that we are using specific configuration for SVN repository browsing by apache with the authentication for virtual host:

AuthType          Basic
AuthName          "Subversion Service"
AuthBasicProvider ldap

In this case I would like to check the possibility to disable the integrated Repsitory Browser as it does not work with our configuration.

Do you have any bug reporting place to report this rather than Atlassian Answers?

Regards,

Areg

[Pablo Beltran]

1. Is it necessary to Uninstall Jira Subversion Plugin when installing Subversion ALM one?

It is recommend un-installing the Atlassian's plugin as you could get some duplicities making difficult to work with both plugins running at the same time. Or disabling it at least.

2. Does the Subversion ALM migrates data from Jira subversion Configuration or it is necessary to add all repositories again?

This feature was dropped in the 5.0 version, so you have to import them one by one. If you have a lot of repositories it would be possible insert them in the database by using a custom script.

3. We are using WebSVN Subversion frontend which uses Apache Auth Basic Authentication via LDAP and seems the Subversion ALM Plugin integrated SVN Web Client does not support that kind of authentication and fails to login to repostory for browsing. At the same time seems Repository Reindexing is working properly.

Do you see any error in the JIRA logs? You would have to enable the org.polarion.* and com.kintosoft.* packages at INFO level from JIRA in order to see any error.