3 ms·
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 Mer
by flurdy 7y ago
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.
- syntheticnature 7y agoI 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.
- BlackFingolfin 7y agoThey 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.
- guy98238710 7y agoOr just provide a link to a tarball download.
- tom_mellior 7y agoCloning it still runs code they don't want to run on their servers.
- andrewshadura 7y agoNo. You just need a dumb webserver, no extra code needed.