Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> June 1, 2020: ... all Mercurial repositories will be removed.

It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).

Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.



This reminds me of patio11's analysis of tarsnap from a few years back: https://news.ycombinator.com/item?id=7523953

"all Mercurial repositories will be removed"

does indeed sound quite at odds with why people use Bitbucket. dissonance re core value-proposition.

I hope Atlassian finds a less destructive way to phase out Mercurial support. Gladly they do have enough time to clarify / reconsider.


That's especially weird since serving Mercurial repositories in read only mode doesn't require any infrastructure apart from a static HTTP server.


Full bullet text:

"""

* February 1, 2020: users will no longer be able to create new Mercurial repositories

* June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.

"""

The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.

The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.

But as you say the second part should be punted way into the future if not never.

Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.


I don't think it's about disk space at all.

Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.


They don't need to allow browsing it; but at least have a minimal page which shows the presence of the repository, and allow cloning it.


Or just provide a link to a tarball download.


Cloning it still runs code they don't want to run on their servers.


No. You just need a dumb webserver, no extra code needed.


They could just convert them to Git repos automatically. If you do that manually, their press release implies that the repos will stay around. So it can't be a disk space issue. Why haven't they offered to do this rather than just remove them?


According to the comments on the OP they tried to make a tool but couldn't make sure it would work in all cases for all repos, so they decided to not make a tool (and delete our repos instead). Such a disgrace.

The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.


The Mercurial data model is a superset of git's. A lossless conversion is simply not possible in that direction.


It’s very expensive to maintain two SCM implementations in something like Bitbucket and maintain feature parity between the two. Poor cost/benefit ratio.

I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.


> we had introduced Git repositories, Git usage grew an order of magnitude almost overnight

Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: