Jira Svn Hooks on transition to BitBucket

[Matt Allen]

We are aware of the possibility to transition existing SVN repositories into BitBucket by following the steps outlined here: http://blogs.atlassian.com/2012/01/moving-confluence-from-subversion-to-git/ . We then plan on deleting/destroying our SVN repository and switch to using BitBucket exclusively in preparation for OnDemand / Atlassian's abandonment of SVN in the coming year. The question that remains is, what happens to the existing links between JIRA tickets and SVN commits? I am aware that such links are generally created by SVN post-commit hooks and that, unless there is infrastructure in place to transfer those links manually, they will be lost after transfering to BitBucket. Advice?

[Matt Allen · Accepted solution]

Jira Support answered my original question, and I thought I would followup here to share. The answer was:

"SVN post-commit hooks are handled by the plugins. The issues will re-link once the SVN data has been migrated to bitbucket and your accounts added again. (The DVCS plugin will re-scan all your commit messages and link commits accordingly.)

High level Example:

• This is a commit comment and this commit fixes JRA-1.
• If you go to JRA-1, not only will you see this SVN commit comment, but it will give you a link to the SVN commit on the JIRA ticket.
• Thus, when you switch to Bitbucket, the JIRA DVCS connector plugin will do the same thing i.e. - no links will be lost.

I hope this helps clarify things. Feel free to respond with any questions or issues.

Cheers,
Jason | Atlassian"

[Semyon Vadishev]

Hello Matt,

Have you considered SubGit for your migration purposes? This tool should work great for you as it allows using both Subversion and Git at the same time. So, you can enable SVN-Git sync for your existing SVN repository, setup Jira for Git repositories and, finally, disable sync once you've moved everything to Git.

We, at TMate Software, are now working on Stash plugin with the same functionality. It's based on SubGit 2.0 which supports bi-directional synchronization of Git and SVN repositories located on different hosts.

Finally, we have already released SVN Importer Plugin for Atlassian Stash which you already may use as a convenient way to convert the history from SVN to Git.

Hope that helps,

Semyon

[Matt Allen]

Semyon,

Thanks for the answer, but it doesn't really address our concern. SubGit looks like a great tool to help the transition, but we're not concerned with the transition per se, and we do not foresee the need of a 'trasitionary period' in which to keep both the SVN and Git repos in synch. We will do a clean cut-over and get rid of SVN instantly. The problem that remains, as asked in the original post, is the problem of existing Changelist-to-Jira-ticket integration, and SubGit doesn't seem to address that. Do you rerun post-commig hooks on every historical commit to reestablish the Jira ticket links after the transfer to Git? If not, I don't see how those links can be maintained...

[Semyon Vadishev]

Hi Matt,

Indeed, SubGit is less helpful in case of cut-over approach.

My intent was to approach the problem by keeping SVN repository and all the infrastructure intact while synchronizing it with a newer Git repository. I'd like to add a couple of points to my answer:

• As SubGit adds necessary SVN revision note to every Git commit it has processed, one can always find the revision and related issues just by traversing the history of Git repository (SubGit puts revisions into Git notes).
• Since version 2.0 (currently in EAP stage) SubGit supports remote mirroring: when one pushes to Git repository, SubGit automatically sends translated changes to SVN repository. In this case SVN server invokes pre- & post-commit hooks, so JIRA gets necessary notifications upon every modification.

I understand that's not exactly what you're asking for. As to the cut-over approach, I think there should be a post-receive hook that updates JIRA with necessary metadata, so you can push converted Git repository somewhere in order to update the issues database. But I'm no expert here and I can't say for sure.

Cheers,

Semyon