Сегодня, 20 августа, в официальном блоге BitBucket опубликовали запись, в которой представители компании сообщают об окончании поддержки репозиториев Mercurial.
Отказ от поддержки Mercurial обосновывают оптимизацией проекта и фокусировкой на более актуальных для миллионов пользователей BitBucket инструментов. Конкретно речь идет о фокусировке на работе с Git-репозиториями. К 1 июня 2020 года из BitBucket Cloud и API проекта поддержка Mercurial будет полностью удалена.
Прекращение поддержки Mercurial будет проходить в несколько этапов:
- С 1 февраля 2020 года пользователи больше не смогут создавать новые репозитории.
- С 1 июня 2020 года пользователи не смогут использовать функции Mercurial в Bitbucket или через его API, а все репозитории Mercurial будут удалены.
При этом отключение функций Mercurial будет проходить в один этап, то есть они будут сохранять работоспособность вплоть до 31 мая.
Это решение было принято разработчиками BitBucket по простой причине: согласно исследованию, 90% пользователей используют Git, когда как доля проектов на Mercurial составляет всего 3%. При этом эти 3% — в большинстве своем старые репозитории, доля новых проектов на Mercurial составляет менее 1%.
Отказ от поддержки Mercurial и концентрация на работе с Git позволит разработчикам не распыляться и направить максимум усилий на разработку в актуальном для клиентов направлении. Тем же, кто работал с Mercurial команда BitBucket советует мигрировать на Git с помощью инструментов вида hg-fast-export или hg-git mercurial plugin.
Комментарии (41)
andreymal
21.08.2019 00:04+3все репозитории Mercurial будут удалены
Ну и что и мешает хотя бы сделать архив?
Chupaka
21.08.2019 11:32Или "мигрировать на Git с помощью инструментов вида hg-fast-export или hg-git mercurial plugin"?
iroln
21.08.2019 15:31Что им мешает сделать хотя бы кнопку «конвертировать проект в git-репозиторий» (так когда-то сделали на google code при закрытии сервиса) или сделать это автоматически с сохранением всех issues/pullrequests? Но зачем, если можно просто свалить эту проблему на головы своих пользователей, многие из которых им платят деньги, и просто всё удалить. Кто не успел, тот опоздал. Какая прекрасная клиент-ориентированность!
Эти ребята явно делают что-то не так. Уверен, что подобные «стратегические решения» им ещё аукнутся. Преимуществ перед GitHub у них почти нет, и они убивают последнее. Эффективный менеджмент в действии.
sentyaev
21.08.2019 00:26+1Интересно почему тех кто платит не оставить на, грубо говоря, текущей версии сервиса, если уж захотят новых фич, тогда будет выбор, либо фичи, либо mercurial.
Да и процент пользователей в этом случае не интересен, может быть есть всего один пользователь размером с Facebook, другими словами интересен не процент пользователей, а распределение прибыли в процентах между, условно, пользователями git и mercurial.
Хороший пример в этом плане Basecamp, хочешь оставайся на старой версии системы, хочешь мигрируй на новую, нравится мне их подход к бизнесу.
KvanTTT
21.08.2019 02:04Ну что же: Git становится монополистом среди систем контроля версий. Какие-то аналоги вообще еще живы? Что с Perforce?
olga0lechk4
21.08.2019 02:22Скажите, я правильно поняла, что если у кого есть репозитории на BitBucket, то им надо их перенести (например на GitHUB)?
andreymal
21.08.2019 03:45Git-репозитории не надо, а Mercurial-репозитории перенести всё равно не получится, потому что GitHub не поддерживает Mercurial
intelligentpotato
21.08.2019 08:07Забавно наблюдать за тем, как инструменты, идущие, казалось бы, в дополнение к твоему бизнесу, призванные облегчить разработку, вдруг начинают гнуть свою линию и загонять тебя в рамки, выгодные им. «Мы не хотим поддерживать Мускул» там, «Мы не хотим поддерживать Меркуриал» сям. И ладно бы эту функциональность оставляли без новых фич и поддержки, но её выпиливают!
customtema
21.08.2019 08:56Мускул третирует Оракл, который его купил, чтобы третировать. С меркуриал тоже явно что-то не так.
pOmelchenko
21.08.2019 09:09Есть мария, но в контексте гитлаба они, вроде как, аргументированно объяснили свою позицию. В облачном сервисе вы и не заметите что у них на бэкэнде. А сэлф-хостед, вроде, пока еще, не дропают вам мускуль «по фотографии», сидите без новых версий и радуйтесь. Захотите обновиться, будьте готовы к миграции. Да и тут, я не проверял, но думаю это будет логично, появится инструмент который поможет это сделать максимально удобно.
eumorozov
21.08.2019 09:13+1Немного жаль. Очень нравился Mercurial. Перешел на Git только под давлением окружения: все рабочие проекты на Git, нет смысла использовать что-то другое даже для домашних.
Но с другой стороны, и понятно. Возможности обеих систем почти совпадают, нет смысла тратить ресурсы на поддержку двух систем, у каждой из которых нет возможностей, сильно отличающей ее от другой. Я даже для хобби-проектов перешел на Git, чтобы не путаться в командах и освободить пространство в голове для более важных вещей.
androidovshchik
21.08.2019 09:40-1В чем именно нравился?) По-сути, во всем должна выигрывать распределенная система. Я не знаком с Mercurial, насчет git скажу, что он не самый понятный в плане синтаксиса, команд. Мб это минус его
sumanai
21.08.2019 09:46-1По-сути, во всем должна выигрывать распределенная система.
Коей и является Mercurial.
Мне Mercurial нравится настоящими ветками и неизменностью истории.KvanTTT
21.08.2019 20:31Так в Git неизменность истории достигается при помощи запрета форс пушов. Но если есть фича с изменением истории, то это же плюс?
sumanai
21.08.2019 09:44+1Видимо нужно переходить на self-hosted решения, а то в ГитХабе блокируют, в BitBucket удаляют репозитории.
Вообще всё больше убеждаюсь, что всё нужно хостить у себя.eumorozov
21.08.2019 10:30Так и есть. Я уже потихоньку начал. Открыл свой stand-alone блог (пока очень простой, даже без комментариев — не хочется модерировать и фильтровать спам), свою почту.
Но монополисты так просто не сдаются. Через неделю после настройки почтового сервера, GMail перестал принимать с него почту под предлогом, что с него идет спам. ip-адрес у сервера фиксированный, я им владею год с лишним. Сразу после создания виртаульного сервера пробил ip по всем базам, что он не в черных списках. То есть спаму в течении недели просто неоткуда было взяться — с моего серевера он никак отправлен быть не мог.
Ну а GMail конечно может про кого угодно сказать: «вы спаммеры!». Возможности аппелировать и обратиться в поддержку ни у одной большой корпорации нет.
Из связанного: наша компания зарегистрировала новый (!) домен для сайта. Когда стали добавлять возможность входа через facebook, выяснилось, что домен заблокирован в FB (тоже якобы за спам! внимание — это новый домен, который раньше не существовал, и на котором еще ничего нет).
Обращения в поддержку в FB длились полгода. Полгода они писали, что проверяют, и писали злобные отписки, что мы их достали, когда просили поторопиться. В итоге, пришлось искать новый домен. А от поддержки FB ответа так и нет. И старый новый домен остается заблокированным....
Увы, монополизм — плохо, но мало кто понимает, пока не столкнется лично с проблемами.
polearnik
21.08.2019 20:59проверьте с помощью wayback machine возможно новый домен таки существовал ранее.
eumorozov
21.08.2019 21:16Проверил: не существовал или не индексировался wayback machine. Да и просто поиск не находит никаких упоминаний домена.
daggert
22.08.2019 00:48К сожалению гугл монополист и пользуется этим очень активно. Мой веб-сайт всецело лежит на моем сервере где в мир торчит только апачи, все остальное режется микротиком и настройкой фряхи. Доменное имя уникально, было куплено 12 лет назад и всегда было привязано к этому белому IP. Однако гугл считает что я дикий спамер и мою почту надо слать в спам у получателя, кроме того — добавив JS скрипты рендерера three.js и сделав там небольшую превью для 3д моделей — мой сайт теперь еще и содержит "вредоносный код".
KvanTTT
21.08.2019 20:33У себя тоже может случиться поломка, пожар, кража и другие несчастные случаи.
Что мешает хостить и у себя и где-нибудь еще? Это же делается очень просто.
TargetSan
21.08.2019 09:56Это те Atlassian, которые уже лет 10 не могут сделать для гита follow file move history в pull requests? Я честно говоря не могу себе представить использование bitbucket для git.
EDIT: Я к тому, что использование BitBucket теперь вообще теряет смысл. По фичам в плане поддержки Git он вчистую проигрывает конкурентам.
green_tree
21.08.2019 10:35Вот я тоже так подумал, что в чем смысл битбакет теперь? Если меня заставят переносить проекты на гит, то я на битбакет не останусь
Chupaka
21.08.2019 11:39Смысл, наверное, в Atlassian. Сложно объяснить начальникам, зачем для репов делать отдельную штуку вместо BitBucket, если в компании уже используют JIRA, BitBucket и Confluence со всякими интеграциями друг в друга.
cadmi
21.08.2019 12:01Надеюсь, что там найдется пара клиентов, которые платят по $20k в месяц за Jira и Confluence и у которых репы в mercurial. И которые спросят «wtf?» у маркетологов, которые принимают решения на основе «опросов stackoverflow», а не глядя в собственный биллинг.
JTG
21.08.2019 12:24+2Примечательно, что когда Bitbucket стартовал, первые 3 или 4 года там была поддержка только hg. Git добавили позже, и вот теперь он всех съел. Увы, часто самыми популярными становятся не самые лучшие решения (начиная с VHS, и заканчивая JavaScript)
все репозитории Mercurial будут удалены
Свинство редкостное.
KvanTTT
21.08.2019 20:34+1Увы, часто самыми популярными становятся не самые лучшие решения (начиная с VHS, и заканчивая JavaScript)
И какое на ваш взгляд лучшее в контексте системы контроля версий?
saga111a
21.08.2019 12:55+1Это жирный гвоздь для меркуриал, очень жаль. Для своих проектов только hg использую, ибо удобней.
А удаление репов это прямо подарок…
shakespear
21.08.2019 14:02Беда и огорчение конечно, очень жаль, Mercurial мне идеалогически нравился больше чем git. Получается публичных хостингов с hg не осталось?
Уже представлю свою миграцию 20+ проектов на hg, связанных между собой подрепозиториями, в git… Ну и хостинг конечно после этого будет уже не BitBucket, хоть с ним было и неплохо все эти годыVioletGiraffe
21.08.2019 15:22Публичные, как раз, остались, SourceForge умеет в hg, насколько я понял. А вот платных и с не конским ценником для маленькой команды (у которой, однако, много репозиториев) пока не вижу.
cadmi
Согласно исследованию, на которое они сослались, 16% «professional developers» страдают какой-то ерундой в виде перекидывания друг другу zip архивов с исходниками и копированием файлов с кодом на сетевые шары. Других professional developers у stack overflow для маркетологов atlassian нет.
Ну что ж, раз команда Bitbucket советует, значит перестанем платить им деньги и мигрируем репозитории «куда-нибудь» :) А github'ом они всё равно уже не станут, как ни «фокусируйся».
lieff
А вы работаете с Mercurial? Не подскажете есть в нем аналог --depth=1, т.е. не качать все, а только последнее состояние?
Aquahawk
geekyshacklebolt.wordpress.com/2018/02/14/how-to-clone-a-large-mercurial-repository А вообще не понятно, настолько ли велик репо с текстовыми файликами? Если вы храните в репо немного (до гигабайта +-) бинарников то www.mercurial-scm.org/wiki/LargefilesExtension Для большого количества арта и бинарей (сотни гигабайт на проект), пока ничего лучше svn не нашлось. Мы так и живём, бинари в svn, код в hg. Я профессионально каждодневно использую hg уже около 5 лет и предпочитаю его гиту.
lieff
Но это же наоборот, нужны самые свежие исходники, а не самые старые. А для самых свежих получается все равно выкачать придется все.
У меня не со своими репами была проблема, в частности у меня долго клонился SDL2.
KvanTTT
А как же git lfs?