> if any of the Cn repositories that read the dropbox copy during that synchronisation may get a corrupted copy of the repository.
Yes, that's why I've been asking whether and how hg will detect this when Cn attempts to pull from a corrupted D. (I wonder what it would take to get Dropbox to do things properly ... maybe it would be easier than getting Atlassian to be more reasonable! Would anyone else be interested in this proposed solution if Dropbox handled .hg folders properly?)
> your scenario seems to assume that Cn repositories will never push
Okay, I get it: don't keep my balls in a single (bit) bucket. There is no one-click button "convert my hg repo to git" or "retain my hg repo" planned. It is totally our fault to choose mercurial as vcs for a number of projects in the first place.
Why "Mercurial"? You selected BitBucket after HG, and BB was just best choice for hg-hosting. Well, if hosting is defining and most important in selection of VCS of usage position - it's OK. For you, other have another priorities
Github provides online and one-click tool for automatic import/conversion from Mercurial (Bitbucket) to Git (Github). Why don't Bitbucket provide similar functionality?
You (Atlassian) compete with Github and you need to provide such functionality anyway (even if you do not support Mercurial). Please provide it, otherwise most of Mercurial users will migrate to Github just because of simpler conversion Mercurial -> Github.
Hi, one more vote to a one-click migration solution. The migration tools suggested in the announcement seem cool but far from easy to execute. This involves a cost in every company that needs to perform this migration, and each one of these companies is paying a premium service to Atlassian. If we have to manage our own migrations due to an Atlassian decision, why should we care to keep hosting our repos in Atlassian?
Please do not remove Mercurial support from Bitbucket!
Mercurial has cross-platform GUI tool TortoiseHg, which works the same way flawlessly for Windows / Linux / OSX. Git does not have the same tool, TortoiseGit does not support Linux / OSX.
If you just do not want to support built-in Bitbucket CI / deploy for Mercurial projects, that is fine - just develop these for Git and disable these for Mercurial. Not every Mercurial project requires built in CI / deploy, and there are third party ones anyway. Just Mercurial hosting is enough and it will be an important advantage to another repository hosters.
Speaking of just 3% of the people using Mercurial at stackoverflow, first of all, 3% is not few from the many hundred housands of the people, also I bet that the percentage of Mercurial users at Bitbucket is higher.
Do not be such evil to Mercurial, it's Python project, just like Bitbucket.
@Alex Breamlong time ago it was not so clear which vcs to choose: git, mercurial, bazaar... BitBucket just gave some carrots to lure on mercurial (and his) side and where we now? Looking back it is clear that it was a wrong way, there is no problem to migrate git repo in contrast to mercurial one.
Classic Atlassian move, only do the minimal necessary work and let the customer alone with his problems and issues. Just look at the JIRA and Confluence issue tracker with tickets that are well over 10 years old and describe basic functionality. Its just sad. I will happily migrate my whole stack to the Jetbrains Toolsuite.
@AmberVH Is anyone from Atlassian going to engage with this post?
There has been radio silence since the first day of the announcement on this thread, despite many people asking some very pertinent questions like:
Can you confirm the level of removal (is everything literally going to be deleted, with no hope of recovery, including projects whose maintainers may not migrate the code because they are not active anymore)
Would you consider continuing to host the code in a read-only format for preservation purposes?
If you won't consider a read-only mode, would you consider converting repos into a static HTML view so that code/meta-data can be accessed still for historical preservation? This would allow you to remove the mercurial infrastructure, but without loss of data for users.
Will you introduce a tool to allow people to download/preserve the meta-data associated with repositories? For example, currently there is no way to preserve pull request history and the discussions contained within pull requests
For those who have paid plans: are you really going to delete code of paying customers on 1st June 2020?
There are probably others I've missed, and I'm sure people would appreciate a response, or at least an acknowledgement that Atlassian realises this asking a lot of their mercurial users and they are discussing ways to address the concerns raised here.
1. Without Mercurial, there is no reason for me and my team not to move everything to GitHub.
2. You are creating extra work for your customers, who, in the middle of their tight development schedules have to convert repos and retrain developers.This is lost time, revenue and missed deadlines.
3. The statement "We will be deleting all Mercurial repositories on June 2020" will lose you the trust not only of the 3% Mercurial users that you despise, but also of the Git users. Even if all my repos are Git, watching what's happening to a fellow Mercurial user, my reaction is "this is not a good place to be".
Nice. You're going to delete my issues database too? Just because I made the mistake of choosing the "wrong" version control system? Thanks ever so much, folks. I love you too.
Atlassian - I did want to say thank you for providing a hosting option for Mercurial for all these years. BitBucket did exactly what I needed it to do - host code in a Mercurial repository. You guys had online hosting with private repositories and it worked out for many years. Surprisingly, the offering was free for our organization. Before this announcement, I would have paid to keep my Mercurial repos in your service.
It seems like just yesterday I was looking at what to do with my source code after SVN and trying to decide between Git and Mercurial. I thought Mercurial was the smart choice because it just made sense after having used SVN for many years. I didn't think such a Linux focused tool would become defacto standard in Microsoft tools and even with their own source code - boy was I wrong on that one. Good thing I don't gamble even on sure bets...
But with the statement that you guys will delete Mercurial repositories I don't see a reason to keep my data under your care. I'm now migrating to Git and GitHub and will be paying a monthly fee to them instead.
For others in this same situation - migrating a 30,000 commit from hg to git has been pretty easy with hg-fast-export. If you use Git Bash it works on Windows if you also install Python and Mercurial separate from TortoiseHg. This is how I did it
mkdir newdir
cd newdir
gitinit
git config core.ignoreCase false
Open Git Bash and run this from that new dir
PYTHON=python ../fast-export/hg-fast-export.sh -r ../local-hgrepo-on-disk -A ../authors.txt
I'm still trying to figure out what I want my workflow to look like without having the branch name embedded in the commit. I really liked being able to see what branch a change was committed against. I'll figure out how to make my workflow work the git way.
Right, ok. This is...... well, it's unbelievable. You've done an incredible job of instantly removing any trust I had in Atlassian, faster than I thought possible. You look at a Stack Overflow survey and think, "Wow! Obviously Git is better because most people use it! We'd better drop the only thing that made us relevant, even though it's clearly the superior system!"
And you know what's even more impressive? You're promising to DELETE all Mercurial repositories with LESS THAN 10 MONTH NOTICE.
Once upon a time there was the country of Bitbucket , founded by people of the Mercurial faith. The Mercurials loved their country and life was perfect. Over time however, the country expanded and the Mercurials became a minority. A 3% minority, according to the government statistics.
So the government decided to organize a little ethnic cleansing, in order tidy up and "better serve" the majority. And set a deadline for every Mercurial to either convert to the majority faith, or be killed.
and would like to suggest that if you do the same, it would be helpful to adopt a positive tone in the hope that the CEOs will see the error of their ways and soften their position. Perhaps I’m being naive, but if there is any chance of some sort of compromise, then this is it. Personally I am not interested in having Atlassian provide a tool for converting to a git repository- as has been pointed out, GitHub already makes it easy to do a bare-bones conversion, and we have several projects which are just not well-suited for git. So if you can honestly say you’re already paying for, or would be willing to pay for, mercurial support, that would be great!
I hope asking about Helix TeamHub here does not sound too rude, in case I can move discussion somewhere else more appropriate. Thanks to BitBucket first, then Atlassian, for providing a good Mercurial hosting service, also for free when team is small.
@Peter Koppsteinwe're trying migration from BB to HTH with a couple of repos, just to get our feet wet. Overall at a first glance they do not seem so different. There are projects containing repositories, you add users or external collaborators, assign roles, and so on.
We could not find anywhere a "strip commit" section in HTH, which instead we have in BB Repository settings. Do you know whether this option is available? For context, where tried on a free tier account.
Atlassian/Bitbucket has done a lot for Mercurial. The blog posts explaining why Mercurial is better than Git were nice, and there's not really anything hypocritical about them removing the support even though they think Mercurial is better. Sadly, I think it makes sense for them to remove it.
However, not giving a minimum of support for existing Mercurial users is crazy. How hard would it be to offer a conversion feature? GitHub does it, and Sourcehut hacked together one that also converts issues in about a day (not very user friendly though).
If you put in a slight bit of effort to make you better than your competitors in this area (not to mention treating your customers/users with a minimum of respect), you might retain your users as well. How exactly are issues stored in the database? Couldn't they automatically be moved to a "new"/converted Git repo on the back end? Boom, it'd be worth it to stay with Bitbucket.
I suppose Atlassian has crunched the numbers, and since they consider Bitbucket Cloud to be an afterthought anyway, they won't bother. A shame. Company goodwill is also worth something.
@vorapoapHg is still technically actively developed so it's not dead, just dead to Atlasian and bitbucket. this was just a big blow to hg as bitbucket was the largest provided for hg.
531 comments