Subversion, FishEye/Crucible (the Source + Review Bundle) on OnDemand End of Service

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.

72 answers

Hi,

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

Stefaan were you able to resolve this?

Not really Ron ... I tried quite a few things without any luck.

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

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.

Two facts, and a question:

  1. Atlassian is ending Fisheye/Crucible OnDemand service
  2. Atlassian is removing GIT-repository from Fisheye, and creating a new product Stash (with simple (?) code-review functionality)

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 facts
Your 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 team
We'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 roadmap
The 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 Pittet
FishEye/Crucible Product Manager

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?

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 Eng
VP, 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.

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.

At the very least, Atlassian should be able to make a quick tool which can link to the existing JIRA user base, and auto create all of those accounts within the bitbucket team container.. it's a one off process, and that would solve my issues, and likely smooth things over for most of the people in my situation..

As it stands now, it seems like Atlassian didn't think this out before throwing out this forced conversion. User management is a big deal, and forcing us into two different user administration systems isn't what we're paying you for.

@Helen, support is nice, but it doesn't each other as much as public forums do.. Even better would be to have comments enabled on the actual instruction pages.. so people like me could tell others that the instructions on this page: https://go-dvcs.atlassian.com/display/aod/initial+clone for example are just wrong and prevent any resyncing against the original svn repository. or I'd add that the clean-git on this page https://go-dvcs.atlassian.com/display/aod/Clean+Up is necessary for any branches to be moved into git. or that the bitbucket-push command on this page https://go-dvcs.atlassian.com/display/aod/Upload needs an admin account for the *-ondemand team as the first parameter, followed by the password, team account (*-ondemand) followed by the repo name.. but alas, people looking at those pages can't receive my help.

I had the same thot Peter re. comments on those pages. However I could see them possibly getting out of hand wrt to the volume of comments. A more open-ended discussion forum would be optimal (and simple/free) IMHO.Thx again for sharing your wisdom!

Peter, Paul -

Thanks for your feedback. You raise a good point Peter, but on the flipside, we wanted to keep the guides and that microsite as orderly as possible, as Paul pointed out.

Why? I'm sure you can imagine that if we had let comments open on all pages there, the possibility of it turning into pages filled with a lot of comments, opinions and discussions would be high. When you have someone new coming in to use the guides, the experience of them realising that they need to trawl through all the comments would be painful and not necessarily relevant.

To avoid this potential mess, this is why we have *this* dedicated forum to let people discuss exactly what you are raising as a point. And for those who are seeking more 1:1 technical support, then via our Support system: https://support.atlassian.com

The instructions on how to create a backup of your SVN repo are also incorrect (step 2 on the first (i.e. "Prepare") page. However I don't mind as I'm going with Peter's suggestion of not doing this, his is a much better strategy.

@Paul - we've just updated the documentation there on the site, after taking into account your comments and Peter's. Cheers

Hello there!

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.

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

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?

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

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,

Viacheslav

Hi Viacheslav

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!

That's great. Thank you. Will wait for a fix.

Viacheslav

FishEye / Crucible / SVN option is displayed now.

But when I press Deactivate and then Apply Changes the Processing dialog stucks and I get the following error in the Chrome debug console:

Failed to load resource: the server responded with a status of 500 (Internal Server Error) https://my.atlassian.com/ondemand/applyChanges?id=...&selectedOrderables=... (I put ellipsises because I'm not sure if it is safe to show post the real data here)

Viacheslav

Hi Viacheslav, I think you unfortunately tried to deactive it when we were making another fix, would you mind trying again the next time you get the chance? I am told it should be working fine now. Sorry for the trouble, thanks!

It worked this time. Thank you!

Hello Helen,

Another minor issue I noticed.

When I create a new user I get an email:

Subject: [JIRA] Username Conflict Notification

There was an error granting default application access to the new user 'testuser01'

We were unable to grant the user access to the following application(s):

  • FishEye/Crucible

To edit application access settings, visit https://selenasoft.atlassian.net/secure/admin/user/ApplicationAccessConfig!default.jspa.

I already have FishEye/Crucible disabled. The account created works fine.

Kind regards,

Viacheslav

Hey Viacheslav, that's a bit odd. Do you mind raising a support case for it at https://support.atlassian.com and we can look into it further there.

Thanks, Helen

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

Helen

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.

Helen

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.

Thanks!

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.

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.

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

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.

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>
to
first.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?

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:

  1. Have the 'first.lastname5 = firstname lastname1 <firstname.lastname1@companyname.com>' address match the registered email address in Bitbucket
  2. Have the Bitbucket user validate a second email address that matches the specific email mapping -- Bitbucket let a user associate multiple email addresses with a single account.
  3. Setup an email commit alias for your Bitbucket repository

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.

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:

  • Is it possible to only deactivate/delete the moved projects/repositories in our SVN that nobody commits something there accidentially?
  • How to we switch the "connection" between JIRA onDemand and SVN to onDemand and Bitbucket (that for every issue the source changed are shown in the tab at the end of the issue)?

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!

Helen

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published 2 hours ago in Jira Ops

Jira Ops Early Access Program Update #2: Let’s talk severity levels

Welcome to your weekly Jira Ops Early access program update, where we’re sharing news and updates on Jira Ops' progress as we work toward our 1.0 release. If you ever want to drop us feedback or idea...

13 views 0 0
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you