Atlassian will be responding to your questions about the end of service of Subversion, FishEye/Crucible (the Source + Review Bundle) on this dedicated thread.
Ask a question by adding a comment below.
Visit the End of Service FAQ to see if we've already answered your question.
Hello there!
How do we link our BitBucket account and OnDemand account for billing/user management purposes?
Answering my own question...
http://go-dvcs.atlassian.com/display/aod/Configuring+a+Bitbucket+account+for+your+team
Will BitBucket be integrated into JIRA like fisheye/crucible is now? Where can we see a comparison of what we will lose/gain as far as the features go?
Hi, you can see a comparison between the main features of FishEye/Crucible and Bitbucket in our FAQ here.
What integration points were you referring to about Bitbucket and JIRA? We explain what the current integrations are here. Let me know if you have any further questions, thanks.
Hi Chris, this depends on whether it is an existing or new Bitbucket account:
If you select to migrate to Bitbucket via your my.atlassian.com account, you will be issued with a new free license. In this case, your new Bitbucket and existing OnDemand accounts will be automatically integrated for billing purposes. Then, when you create new users in OnDemand, you can also invite them to Bitbucket simultaneously. More info is available here.
Unfortunately, if you want to link an existing Bitbucket account with OnDemand for billing/users, it is not currently possible.
I hope this answers your question, thanks.
How does these end of life OnDemand products affect the self hosted versions?
1) Will there still be any subversion support?
2) Will subversion plugins be maintained?
Hi Norman, there is no impact at all on our installed, self-hosted versions of FishEye and Crucible.
We are continuing to invest in both self-hosted products.
1) After 15 October 2013, there will no longer be any hosted Subversion support. However you can continue to use Subversion, as it will be supported until the end of service period lapses. Our installed versions will continue to support Subversion.
2) If you're asking about the JIRA/Subversion plugin, then yes that is still is an Atlassian-supported plugin to hook up Subversion to self-hosted JIRA.
Hello,
I'm evaluating OnDemand and I decided not to use Subversion and FishEye/Crucible.
I removed FishEye/Crucible for all users in JIRA Admin > User Management > Application Access and I disabled FishEye/Crucible in: JIRA Admin > User Management > Default Application Access but I can still see the "FishEye + Crucible" in the app switcher:
Is it possible to completely remove Subversion and FishEye/Crucible from my OnDemand instance?
Thank you.
Viacheslav
Hi Viacheslav
If you want to stop using FishEye + Crucible completely and have it disappear from your navigation there, then you'll need to log into my.atlassian.com and cancel your FishEye + Crucible subscription. After you cancel, you will no longer be charged for FishEye + Crucible and it will subsequently be removed from your OnDemand instance (this should take approx 10mins for it to take effect).
Cheers
Helen
Hello Helen,
I can see that FishEye/Crucible OnDemand evaluation is active for my account
but when I press Configure there is no option to deactivate it
I remember it was there before but it seems that the option to configure this product disappeared after October 15th. I think it should be displayed at least for those customers who are already using FishEye/Crucible so they could deactivate it. Right?
Kind regards,
You're right, it should appear - that's a mistake on our end which we're putting a fix into the system today. In a few hours, you should be able to see it appear as a line item that you can then deactivate. Apologies for the error!
We signed up for an OnDemand trial on October 9th. Will we be able to utilize the hosted Subversion until End of Support or will we be required to migrate at End Of Trial ?
Hi Ian, if your OnDemand trial is still ongoing and you don't cancel it, it will start charging your credit card after 30 days. If this happens, you will be able to continue using Subversion and FishEye/Crucible up until 15 October, 2013 but keep in mind that you will also need to migrate off it before 15 October, 2013.
FYI, we provide details about it in the FAQ.
I'm curious if it's possible to incrementally move from SVN to Bitbucket. We'd like to do this in pieces rather than for all of our projects at once.
Hi Robert, are you interested in moving to Bitbucket and using Git or Mercurial?
If Git, our migration documentation here does explain how to move from SVN on a project by project basis, as mentioned in the first sentence of that page. However, note that our Mercurial guide is structed on an entire-repo basis.
Once we choose the move to Bitbucket Hg migration option, do we instantly lose access to our Subversion repositories? Do we have a transition period of say a week where we can shuffle things around and troubleshoot issues?
Hi Xiao
No you do not lose access. You will continue to have support and a working Subversion repository up until 15 October 2013, regardless of which migration path you choose to activate.
Thanks
Two facts, and a question:
Does this mean that Fisheye/Crucible is a dying product (for installation on our own server)? Or is Atlassian still actively developing Fisheye/Crucible. Are you going to develop new features/versions for FishEye/Crucible?
If the answer is something along the lines "FishEye is not going away", can you please state how big development team you are going to have on FishEye 6 months from now, compared to 6 months ago? And do you have any roadmap for FishEye (to ease my distress)?
Thanks!
Hi,I'll go straight to the point: FishEye/Crucible isn't going away and we're actively investing in it.Now, I'll break it down to the different points that you mentioned:(a) The 2 factsYour facts are right. But those decisions were hard calls that we had to make to give FishEye/Crucible a better future. These applications were not originally architected for the OnDemand platform nor FishEye/Crucible was designed to handle repository management. We tried for a long time to stretch the original nature of the products and we decided then that it would be better to get back to its original strengths: be a great solution to index, track and review code across different SCMs behind the firewall. More about these decision can be found in the announcements that we made:- End of life announcement of Internally Managed Repositories for FishEye- End of life announcement for FishEye/Crucible OnDemand(b) The teamWe're growing the team. The size of the engineering team 6 months from now will have doubled from what it was 6 months ago, you will be able to judge it yourself by looking at the release notes for each release where the people on the FishEye/Crucible team are listed.(c) The roadmapThe current priority is to improve the performance of FishEye/Crucible for large instances. In other words, our short term focus is on making sure that existing features are fast, even with large sets of data. To achieve this goal we are revamping the way we store and treat data coming from SCMs but we are also working on making everything more intuitive and simpler to use as we believe that usability helps a lot on productivity. All new improvements and features are planned to achieve this goal.I hope that this helps to understand better our plans and if you still have some concern don't hesitate to get in touch with me directly. You can send me an email at spittet@atlassian.com.Cheers,Sten PittetFishEye/Crucible Product Manager
My company's software development team is digesting the information in the announcement and is very excited about moving from SVN to Git. The team has asked:
"If we decide to use GitHub instead of BitBucket for SCM, will there be integration restrictions with...?"
1.) Will Atlassian OnDemand JIRA still have connectors to GitHub after the migration? Will GitHub integration still be possible and maintained going forward?
2.) Will Atlassian OnDemand Bamboo still have connectors to GitHub after the migration? Can we use our existing build plans if our source code is moved from SVN OnDemand into a GitHub repository instead of a BitBucket Git repository?
The team is very excited about the changes happening to BitBucket, but wants to ensure that they understand all of the potential ramifications to integrating issue management, continuous integration, etc. when they make a choice regarding source code management.
Thanks, Matt W
Hi Matt, it's great to hear that your team is keen on embracing Git!
Regardless of whether you're using Bitbucket or Github as your SCM, Atlassian OnDemand still allows for the same integration experience. To answer your questions more specifically:
1. Yes, there is still a connection you can use between JIRA OnDemand and Github after migrating. Here's more info on how to set up the integration: https://confluence.atlassian.com/display/AOD/Linking+a+Bitbucket+or+GitHub+repository+with+JIRA+OnDemand
2. Yes, Bamboo OnDemand still allows you to connect any build plan to a Github repo, whether it be a direct specific or shared repository: https://confluence.atlassian.com/display/AOD/Specifying+the+source+repository
Hope that helps, cheers.
As of today Bitbucket and OnDemand have different user accounts. DVCS JIRA connector can infer an association between user accounts, but as far as account management is concerned (passwords, permissions, etc.) these two systems are completely separate. Even though we're happy to embrace DVCS, if we switched from OnDemand SVN to Bitbucket today, we'd be required to have all the users creating yet another account and yet another password, and then some amount of admin overhead to make sure all permissions are set correctly.
Could you advise if there any improvement for the situation planned for the next 12 month, while migration window lasts?
We use JIRA integrated with Subversion/Fisheye/Crucible in OnDemand. Will BitBucket be integrated the same way? For example, when we commit a change using Subversion, we include a JIRA issue number which then links the Issue to the Source Code and vice versa. Will this linkage capability still exist when we convert? Thanks.
Hi @rosemary I believe you are referring to the feature of Smart Commits. This feature is also available in Bitbucket OnDemand - check out more info about how to get it working: https://confluence.atlassian.com/display/AOD/Enabling+DVCS+smart+commits
I am planning out the move of my company's svn repo to git. One of the issues we have had in the past is that Jira breaks if we open a ticket that had code committed against a tag or branch that no longer exists. With that in mind, what can we expect once I have our repo moved into git? Will we be unable to work with past tickets due to our svn repo no longer being active? Will Jira recognize the new repository when it tries to reference old commits?
I will be pulling over the entire svn history when I do the migration. I just need to know what little creepy crawly nasties I can expect in Jira from the move.
Hi Igor,
Yes - we are investing in improving the user management across multiple systems including OnDemand and Bitbucket. You will start to see a consolidation of user accounts in the next year. We are not sure if it will all be complete by October 2013, but we are striving to complete this work within 2013.
Cheers,
Audra EngVP, Product Management
Audra, thanks for the information. We'll wait with migration until later to reduce admin overhead and security concerns. Hope some form of synchronisation for logins and passwords will be introduced before by October 2013.
Hi,
we've been using JIRA/Subversion integration (i.e. issue linking) extensively. Are we going to lose several years worth of backlog on which JIRA issues are related to which changes in the codebase, and who did those changes, if we migrate away from Subversion/Fisheye?
And will we lose that information anyway, if we decide to migrate to self-hosted Subversion instead? In fact, FishEye/Crucible stuff is nice-to-have in the first place, but maintaning the "source history" is critical for our software development process.
Hey guys,
One thing I really like about our current Atlassian setup (we have Jira, Confluence, Bamboo, and Fisheye) is that we can use the Fisheye "hooks" to trigger/update changes in Jira Issues tickets (like comments and time spent).
Running local versions of Fisheye is not an option for my company, so I am wondering how I will get this functionality with the changes that are coming in October of next year.
Thanks much in advance,
Jim Reid
In the migration process, you'll be exporting your entire history to a different system. This will, of course, include the commit messages with that history including the JIRA issue keys that you've mentioned and the user's who performed the commits. Look over the guide for full details on how to do this.
Lastly, you have a full year for the migration and we recommend you perform some testing in advance anyway. Take some time to perform some test migrations to see if the data is how you expect it.
This functionaility is available through the DVCS connector that is configured and included within your OnDemand instance. Setting up Bitbucket OnDemand will automatically configure this for you even. For more information as to how this now works, please review our docs.
As a result to the announcement, I am trying to migrate my Atlassian OnDemand hosted SVN to Git, and I am following your guide at http://go-dvcs.atlassian.com/display/aod/Migrating+from+Subversion+to+Git+on+Bitbucket
So in fact, I downloaded a backup of my SVN, installed that in a local repository on my mac, then did the initial clone, then set up the Syncing ... but now comes my problem.
Our developers will still be comitting to the hosted OnDemand SVN. From what I can see, the sync part is only syncing between my local SVN and my local Git. But how do I actually get the changes made to the OnDemand SVN into my local SVN so it can be synced with the git repository ? Or isn't that the way you should approach this ?
Regards,
Stefaan
Hi, I have a query on user invitation on Bitbucket for migration. After you create the team account from my.attlissian.com the users needs to be invited to the groups. Should the group names and/or usernames <emailaddress> be same as in OnDemand.
For e.g. we have say 'developer' group with 5 users in OnDemand using SVN. The authors file will be generated for these 5 users with usernames and emailids as in OnDemand SVN. Like: first.lastname1 = firstname lastname1 <firstname.lastname1@companyname.com> tofirst.lastname5 = firstname lastname1 <firstname.lastname1@companyname.com>
When you create groups and invite users on BitBucket is it necessary that the group name should be 'developers' and the invitations should be send for the above mailids itself. And when the users accept invitation and sign up for accounts should they be using the same usernames as in OnDemand?
Stefaan were you able to resolve this?
Hi Ron,
The usernames and groups in OnDemand and Bitbucket do not need to be the same.
What I think you may be referring to is the mapping of your old subversion username commits to the new code hosting system, Bitbucket. Git and Mercurial map commits based on email addresses, not usernames. If you would like the historical commits properlly mapped to your new Bitbucket users when converting your Subversion code, you will need to either do one of the following:
Hope this answers your question!
Hi Justen, Thank you for the response and the tip link. Good to know that email addresses are used not username for integration between jira and bitbucket. Most of the usernames are already taken or the issue was we use firstname.lastname as usernames in OnDemand. But Bitbucket does not allow the '.' (dot/period) for its usernames.Thank you once again for the support.
Not really Ron ... I tried quite a few things without any luck.
I can't express how important this is to us as well. Telling all of our developers that they have to go and create a bitbucket account before I can even add them to our git repo and having them all do that correctly is a management nightmare. It would be better at the very least if the invitation from the team repo would work with accounts not already setup & essentiallly auto create the account for the person.. As it is now, the "invitation" doesn't work if the user doesn't have an account already, which confuses most people and introduces a poor chicken and egg situation which could have easily been avoided.
FWIW
Am I the only one concerned about this forced migration for small software companies who do not really have the resources to move from SVN to git and to manage things afterwards?
I know it's all very exciting, but git is very different from SVN and we have just two employees with some prior git experience - (neither a real git expert) .
And both have witnessed the git repository getting screwed up - 3 times at two different companies over the course of about 14 months - it took many, many hours of work by real git experts to get things working again.
(And we've never seen this happen with a combined experience of probably 10+ years with SVN)
Bottom line, I think this forced migration policy is an extremely high risk endeavor for small software companies with no real git experience and because they don't have experience with git they don't know what they're getting into.
BTW, Sorry to be so difficult, but why is the migration option once selected, final - what's the rationale for that given that it's quite possible that after starting down one path we decide we'd like to change - that doesn't seem to be a very "agile" approach - Thx Colin.
Hi Colin, thanks for raising your concerns and feedback, which are all very valid. I apologise for putting your team in this position. We obviously don't like to upset our customers and we were aware that this wasn't going to be a easy migration for you all. As I'm sure you can guess, this was not an easy decision for us to make. We realise this forces a decision point for our customers such as yourself to migrate or move off of our service. We came to the conclusion that maintaining multiple hosted repository support for both DVCS and Subversion was untenable for us for the long term and would not allow us to focus and improve the overall service for all customers.
If it helps, we added some Git/Hg training guides on the migration microsite if you decide to make the switch: http://go-dvcs.atlassian.com/display/training/Training+Home
Have you considered the option of staying with SVN? There is still the option of going down the path of using FishEye/Crucible Download. Whilst you may not be able to host this on your own server being a small company, we do have partners that may be of service to provide hosting for you: http://go-dvcs.atlassian.com/display/godvcs/Help (see the right column for list of experts).
In relation to having the migration option being final: this is to emphasise to customers not to take this decision making process lightly.
Again, thank you for your feedback for what it's worth, we appreciate your support and the time you've spent providing us your thoughts. Let me know if you have any other questions.
Cheers, Helen
We have migrated some of our projects/repositories already to bitbucket and all worked fine. Two questions to this:
Hi Christian,
In answering your questions:
1. Yes - you can make particular repos read-only within JIRA adminstration. Instructions on how to do this can be found here: http://go-dvcs.atlassian.com/display/aod/Switch
2. This "connection" should be automatic once you've got Bitbucket working and linked to OnDemand. If you followed the proper migration steps to Bitbucket, then JIRA and Bitbucket would have been automatically configured to speak to each other. Otherwise you will need to set up the DVCS connector yourself: https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA
Bitbucket can be run in parallel with your SVN if you've still got that running. As long as you have made a commit, it should show within the Commit tab.
Hope that helps, cheers!
Just starting exploring migrating from SVN to git/bitbucket. Initially I'm doing a test run-through and I'm not concerned about folks checking stuff in while I'm doing my test migration. If I kick off a backup of our SVN repo will it lock the repo while the backup is running? Assuming so, how do I know how long it will run for? Also, the migration site says to do this backup/dump myself but comments from Atlassian empls elsewhere on the site say to log a support ticket to get an export, which should I do? Thx.
To answer your questions @Paul O'Flynn (I can't directly respond to you above because you made yours as a comment and not a question... I think):
1. Locking the SVN repo during backup
You can still make commits to the repo after starting the backup process. If you don't want this to happen, than you need to change the permissions of the repo. Here's more info about how to do that: https://confluence.atlassian.com/display/AOD/Configuring+default+repository+permissions
Once you start the backup, the screen will inform you when it's finished.
2. Creating the backup
You can create the backup/dump directly from your instance yourself. There's no need to contact us to create the dump, unless of course you run into issues during.
I agree with Peter - this is a huge imposition, especially on small software companies that really do not have the resources for this forced migration :-(
Maybe we should start an "anti-atlassian-forced-migration" Facebook group?
@Paul Don't bother with the backup dump file.. that instruction from Atlassian is wrong if you expect to be syncing the svn and git more than once.. if your repo isn't small or you have many users that need to learn about git, then you'll likely be doing multiple syncs to figure things out..
Basically, at the step in the instructions where you build the git from the local svn repo, point it instead directly at the svn on your jira instance.. It will take longer, but then you can do "git svn fetch" to continue getting updates from the svn repo.. (followed by a "sync-rebase" and "bitbucket-push", to push those changes to git)
if you followed their instructions, then you can only get updates from your local svn dump.. which you'll be hard pressed to update with any changes from the svn repo itself (there are no instructions I could find on how to do this)..
Shame on Atlassian for forcing this on us and doing so little to run through this on their own first..
I'm not so much against the migration itself.. git has promise and a year should be long enough for folks to plan around.. I'm just annoyed at having to setup every user individually, migration instructions which are wrong and misleading, and the loss of some of the fisheye functionality (reports on the repository)
Thx Helen & Peter for some really good info.
One other question - is this really the best place to ask migration related questions? Isn't there a proper forum somewhere? I'm anticpating having a lot of qs and am very interested in 'real world' experiences like Peter's.
Paul
@Paul, I got an e-mail about your comment but it seems gone
To answer.. this seems the only place to asking migration questions.. all of the other pages telling us how to migrate (and there are multiple with differing instructions) don't allow comments.. Atlassian is losing my respect.
For such a large (and potentially dangerous) undertaking I'm very disappointed that this the only place to ask qs :-( The migration guide is a nice start in my mind but that's all it is really. I've used git in my last job, but never atlassian and never svn but I got dumped with this migration project and will definitely be asking qs... Oh well... Thx for your responses Peter.
I agree, extremely risky migration for many of us - I think Atlassian have badly mis-calculated on this one
Hi Peter and Paul - if you have migration questions, we indicate on our migration website that you can raise a support request. We'll be able to help you out as much as possible: https://support.atlassian.com/secure/CreateIssue.jspa?pid=10840&issuetype=50
Otherwise, yes we decided to make use of this Answers thread so that all public q/a and comments can be consolidated in the one spot for ease and everyone's benefit.
We have done a migration about a month back there were about 35 svn projects and about 30 users. All went well but the only glitch was the real time sync that is mentioned. As peter has mentioned what the sync go as far as as the local repository that you restore from backup. It does not sync from the actual JIRA SVN. We ended up doing the entire migration during a weekend and swtiching over to GIT-Bitbucket from the preceeding Monday. We had setup a test GIT project on Bitbucket to educate our users. And did a sample migration of some of the projects and documented it. On the migration weekend the Bitbucket was completely wipedout and redid the migration from our doc. Now all is going well.
Are you quite sure the backup wont lock the repo?? There's a big warning on the backup page (pasted below) that seems to say otherwise.
I tried running git clone directly against the SVN repo per Peter's (very sensible sounding) suggestion but it runs for days and fails, usually due to network timeouts while trying to contact atlassian.com (dunno why, the machine isn't running out of memory or anything, but any job that runs for 3+ days is probably going to get into trouble at some point ;-). Maybe I need to somehow trim the SVN repo first..
FishEye and Crucible will be unavailable until the backup completes FishEye/Crucible or Subversion will be unavailable while a backup is being generated. The time required to complete the backup is dependent on the size of repositories and the number of repositories and reviews in your instance. Large repositories may take several hours to complete
FishEye and Crucible will be unavailable until the backup completes
FishEye/Crucible or Subversion will be unavailable while a backup is being generated. The time required to complete the backup is dependent on the size of repositories and the number of repositories and reviews in your instance. Large repositories may take several hours to complete
It looks like you're new here. Sign in or register to get started.
![Photo of Justen Stepka [Atlassian]](https://us.v-cdn.net/6038660/uploads/avatars/94/20/n9420891607aa30546628070942a3359f.jpg)
