What environment should a SVN plug-in target to embrace the biggest amount of enterprise customers?
A) JIRA + Subversion plug-in
B) FishEye (for Subversion)
The plug-in will display revision graphs for any versioned artifact with the following major features:
* run on browsers (HTML 5 graphs).
* support for merge lines.
* display JIRA issues related to revisions (throug JIRA issue keys embedded in commit messages).
PS: I've attached an old screenshot for an antrifact version at Apache.org
Are you planning to develop a plugin and asking what platform you should develop the plugin against?
You will likely have an easier time writing the plugin against FishEye. FishEye already indexes subversion repositories and provides numerous graphs, and you may find it easier to query the data you're looking for from FishEye's existing index than to query it from SVN.
@Richard, the indexes no matter in this case, because the revision graphs require an extremely fast index engine. This is the plug-in major feature: provide its own high performance index system (moreover a history visualization).
In general, FishEye should be easier to integrate because it provides a public API, but for me this is less important than the market share and the customer trend. Well, it looks that many customers are moving from SVN to GIT, mainly because the branching power of Git (and others only because the buzz than Git is better). But many of them are using Subversion and they are happy with it. The question is still open: Do it on FishEye or on the Subversion plug-in for JIRA?
The guess is that many companies would like a button providing the Subversion revision and getting the merge history of any versioned artifact in a visual way, accurately, fastly and... with the JIRA issues related to the commits on the same graph on their browsers. Providing a branching/merging visual information on Subversion more powerful than anyone could get from Git is the goal. Of course, at the command line and the merging performance levels, Git would still be superior. But what is more appealing...? Getting the best information prior to merge or making a merge faster?
Finally, I chose JIRA as development platform as it brings new features to Subversion users like workflows, collaboration, etc. that make the result much rich and interesting compared to FishEye. Indexing the whole Subversion repository has been an easy task, so I did not see too much advantages on re-using this feature from FishEye.
Here is an overview of the integration:
Under the JIRA home directory, extacly in the
For the entire Apache's public Subversion repository (+1.5 millions of commits) it takes < 8.5 Gb on Windows.
It indexes the full repository history (including the changed paths) but not the file contents.
Does it add anything to JQL?
No, but you can use standard SQL to access to the indexed data from a database web console provided by the plug-in.
How often does it check for new commits?
This can be scheduled from the Atlassian services administration view. The minimum interval is one minute.
Can a commit hook trigger the check?
To keep this thread up to date:
I developed it: Subversion ALM. It is a free add-on that users interested in it can found here:
The commit graphs are already supported even displaying issues and support for merge is coming soon.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs