How to install svnwebclient for jira subversion plugin?

jayasingh

Hi,

We are evaluating both the jira subversion plugin[Atlassian Owned] and the subversion ALM plugin[Kinto Soft Owned]. In subversion ALM plugin web client is the inbuilt feature. But for jira subversion plugin its not. I have gone through the following pdf for installation of svn web client http://blog.polarion.com/wp-content/uploads/2013/07/Handout_SVN_Webclient_Installation.pdf

But i am not succeeded with that . Can any one help in this

Steps i followed for the installation

Step1: Downloaded the svnwebclient war file

step2: Deployed the war file using Apache [on jira installed machine ]

step3: changes made in web.xml file

Not sure which url i have to give after selecting web link for View Format,Changeset Format,File Added Format,File Modified Format,File Replaced Format,File Deleted Format

Whether these svnwebclient is necessary ? or i can simply i can add the repository to jira subversion plugin and configure the URLS pointing to the repository?

Contact Kintosoft

Thank you for your interest in the Subversion ALM plugin and also by bringing an interesting comparative about two plugins....

Even I might understand people want to compare both solutions:

ALM plugin vs (Atlassian's plugin + 3rd party Subversion web client)

it is not really a comparative about two solutions. It is a comparative about two vendors:

Atlassian VS 3rd party small vendor

ALM is so clearly superior to the Atlassian's plugin that there are not any reason to use the Atlassian's plugin. Briefly: ALM was born as a fork of the Atlassian plugin so almost the 100% of features provided by the Atlassian's plugin are also supported by ALM, it means you can do nothing with the Atlassian's plugin that you could not do them with the ALM plugin too. While the opposite is not true: the ALM plugin brings a lot of features not supported by the Atlassian's plugin. So, there is not any benefit in using the Atlassian's plugin.

So, why are companies still using the Atlassian's one? This is a mistery. The only one reason is due the vendor behind each solution or simply they did not realize there was a better alternative.

The only one feature supported by the Atlassian's plugin and not by the ALM plugin is that you can configure any 3rd party web client for Subversion (ViewVC, FishEye, Polarion, etc.). While you cannot do it with the ALM plugin as it brings with a CUSTOMIZED version of Polarion. But there are good and powerful reasons for this...

In your particular case, using Polarion as independent server to browse on Subversion has not too much sense because:

• it would require you maintain a secondary server (Tomcat) so it would increase your adminsitration costs/effort (you have to register every Subversion repository twice, once on the Atlassian's plugin and once on Polarion itself in order to keep them synchronized and you would also have to configure some urls as you have discovered now). All this stuff is done by the ALM plugin automatically.
• Polarion supports ssh+svn access protocol well, while the Atlassian's plugin not. So if you need to use such protocol you couldn't. However, the ALM plugin extended the ssh+svn support from Polarion to the Atlassian's plugin.
• With the ALM plugin, you can also use Polarion as Standalone Web Client for Subversion, it means you can access directly to the Polarion browser ignoring JIRA just like it was installed on Tomcat directly. Therefore, with the ALM plugin developers can use Polarion without requiring a JIRA user account. There is an option for that, so you could also require that everybody using Polarion must be logged in JIRA first.
• The Subversion Web Client is used by Polarion inside its products, but as Standalone web client it has been discontinued, so you would use an unsupported product in production.
• The Polarion's browser has been customized and improved a lot by the ALM plugin. Some examples: it has a GUI for configuration rather than requiring to modify the web.xml file. The discontinued library used by Polarion to highlight sources has been fully replaced by a well maintained alternative which highlights much more languages. Commits graphs (displaying JIRA issues) and commits calendars are provided by the ALM plugin only. The JIRA issues are recognized and highlighted by the ALM plugin on Polarion while browsing, etc.
• The ALM plugin supports JQL for Subversion which is a critical feature for traceabilty.
• The ALM plugin is integrated with Agile so you can see commits on Scrum and Kanban boards.
• The ALM plugin is better maintained, so you can get fixes for bugs or get new features implemented within few days.
• And there are much more features are in the ALM plugin's roadmap, like support for tracking merges, comparing Office and PDF document versions, etc.