Форум: Техническая поддержка

Добрый день!

Битбакет еще в августе объявил, что с 1 июня 2020 года они отказываются от поддержки репозиториев mercurial: https://bitbucket.org/blog/sunsetting-m … -bitbucket, https://habr.com/ru/company/itsumma/news/t/464455/
С 1 февраля они прекращают создание новых репозиториев в формате mercurial.
Какие у вас планы в связи с этим?

PS: Для своего проекта я сконвертировал репозиторий x502api с субмодулями с помощью https://github.com/frej/fast-export

Добрый день.

Да, есть такая проблема. В любом случае репозитории будут переводиться с mercurial на git, тут в общем особых вариантов я не вижу, mercurial сейчас мало кем поддерживается.
Вопрос только в хостинге, наверно все останется также на bitbucket, но возможно еще посмотрю в сторону gitlab. Где-то с конца февраля по мере возможности буду переводить на git, пока не было времени. В любом случае до мая все должно быть переведено, т.к. в мае mercurial-репозитории будут удалены.

У Вас с преобразованием все прошло без проблем? Вся история сохранилась? В истории он во всех коммитах корректно сопоставляет коммиты из субмодулей?

Отредактировано Алексей L Card (21.01.2020 16:25:23)

История сохранилась. С субмодулями проблема:
Вариант переноса субмодулей так как написано в https://github.com/frej/fast-export/blo … MODULES.md не сработал.
fast-exportу понадобился субмодуль lib/timer, хотя такой сейчас не используется. Нашел у вас такой репозиторий добавил его в mapping файл.
После этого получил следующую ошибку

Победить эту ошибку не удалось. Возможно как-то не корректно обрабатывает ситуация, с удаленным субмодулем. С разарботчиком не связываля.
Поэтому субмодули я добавлял уже в готовый x502api вручную.

видимо в старых коммитах есть ссылка на timer, а не ltimer (когда-то давно он действительно переименовывался), соответственно ему для конверсии всей истории видимо нужно маппинг настроить для ссылок из всей истории проекта... хотя тогда не понятно, почему выдает ошибку.
попробую тогда конверсию с этого проекта начать, посмотрю что выйдет...

Похоже ошибка с удаленными субмодулями актуальна. В issues fast-export последние две темы посвящены похожему сценарию.

Ради эксперимента попробовал вчера конвертнуть с помощью hg-git: https://github.com/schacon/hg-git
Безуспешно - любая команда связанная так или иначе с git вываливается с ошибкой.
Пробовал и версию с github по ссылке и пакет из Ubuntu - mercurial-git, результат одинаковый.
Похоже, что более актуальная версия лежит тут: https://dev.heptapod.net/mercurial/hg-git но я ее не тестировал.

В этом плагине вероятно поддержки сабмодулей вообще нет, по крайней мере в TODO submodules стоит в разделе maybe и под вопросом :-) Правда и TODO уже 11 лет может что-то и сдвинулось, но по документации это не понятно.

По поводу ошибки с packages, то это был в истории такой подрепозиторий, который ссылался на cmake_obs_packages, который был перенесен потом в sdk (вот коммит с изменением .hgsub - https://bitbucket.org/lcard/x502api/com … 2df4cb4d7a.
Соответственно, если сконвертировать cmake_obs_packages и сделать ремап "packages"="<путь>/cmake_obs_packages", то само преобразование пройдет успешно как бы...
Но вот корректно работать с полученным репозиторием все равно нельзя будет из-за как раз одной из issue в ht-fast-export и git submodules init вернет

Они вроде там отвечают, посмотрим что напишут...

Кроме этого (174) в .hgsub были изменения в 42 и 53 коммите.
lib/timer удален в 42 коммите.

Подобрал все сабрепозитории, добавил в мапинг файл и похоже все сработало.
Кроме текущих сабреп нужно еще timer и cmake_obs_packages.
Проверил историю - сабрепы откатываются куда надо.

Соответствие номеров комитов hg и гит sha можно увидеть в .git/hg2git-marks
Для того что бы сабрепы синхронизировались после checkout я давал команду:
git submodule update --init --recursive

URLы на сабрепах надо изменить на правильные, после конвертации они ссылаются на локальные репы на диске, которые были прописаны в мап файле.

Все перепроверил с нуля. Сабмодули по истории синхронизированы.
Доплоню процесс парой замечаний:
1.Похоже что после того как сабмодули отдельно сконвертированы их нужно сразу заливать в окончательное место расположение (на битбакет или куда-то еще) и в мап файле указывать уже URLы туда. Т.к. при конвертации пути к сабмодулям прописываются в .gitmodules, а он коммитится как обычный файл и сохраняется в истории гита так же как и .hgsub.
Вообще не обязательно сначала конвертировать сабмодули, т.к. при конвертации основной репы обращения к сабмодулям не происходит, достаточно того, что они прописаны в мап файле. Проверял. Но при этом столкнулся с таким нюансом: при выдаче git submodule update --init --recursive процесс спотыкается на одном из удаленных сабмодулей и в итоге ничего не происходит. Но это можно обойти, если обновлять сабмодули по отдельности, только те, что указаны в текущем .gitmodules. Например так: git submodule update --init lib/ltimer.
Но в целом, думаю что правильней начать все таки с сабмодулей.

2.Номера из hg в .git/hg2git-marks увеличены на 1 - в файле они начинаются с 1, а в hg с 0.

Это Вы про fast-export или hg-git?

Если про fast-export, то:
1. для коррекной конверсии необходимо каждому коммиту основного репозитория сопоставить коммиты подрепозитория уже сконверитированного в git, соответственно без конверсии подрепозитория в git не очень понятно как он может это сделать. Когда я указал удаленный URL в мапинге скрипт явно писал предупрежедения о том, что не может получить доступ такой-то ревизии подрепозитория, т.е. он все же к ним пытается обратиться, просто не прекращает конверсию, если не смог. При этом с удаленного сервера он не может их забрать. У меня получился в результате при такой конверсии проект вообще без субмодулей.
2. То что git затыкается на git submodule update --init --recursive как раз и говорит о том, что не все сконвертировано удачно. У меня была проблема, что fast-export оставил подрепозиторий packages (т.к. не смог понять, что он удален) при этом в .gitmodules его убрал, в результате чего git пытался его инициализировать и не мог понять откуда его взять. В общем эта проблема сейчас там обсуждается на сайте fast-export, вроде есть человек который занялся попыткой ее исправить, надеюсь у него получится.
3. С путями я думаю перейти на относительные пути к субмодулям, тогда можно воспроизвести дерево проектов с сервера на диске (для bitbucket это общая директория, т.к. там нет групп, а в gitlab можно полноценно делать рекурсивные группы, соответствующие директориям файловой системы) и они будут действительны как при локальной конверсии, так и при ссылке на сервер.

Отредактировано Алексей L Card (22.01.2020 19:50:08)

К тому же относительные пути не привязывают подрепозитории к способу доступа к репозиторию (т.к. если в субмодулях стоит путь с https, то чтобы получить доступ к репозиторию только по ssh придется изменять конфигурацию путей к субмодулям), как описано тут например https://docs.gitlab.com/ce/ci/git_submo … dules-file

fast-export судя по всему явно просматривает директорию .git всех субмодулей по указанному url и ищет в ней соответствие ревизий git с ревизиями из hg, поэтому ему нужно наличие всех сконвертированных субмодулей на диске, а не на уделенном сервере

По поводу hg-git, то сколонировал последнюю версию с https://dev.heptapod.net/mercurial/hg-git, в результате он сконвертировал проект вообще без создания субмодулей. И судя по этой issue https://dev.heptapod.net/mercurial/hg-git/issues/222 действительно конверсия субмодулей работает только при пртировании из git в hg и то просто делая в .hgsub ссылки git-репозитории без их конверсии или какого-то маппинга, а в обратную строну из hg в git вообще никак не поддерживается.

Да, вы правы.
Вчера для эксперимента удалил сабмодули и провел экспорт. Но похоже в процессе что-то напутал, т.к. сабмодули после update по одному у меня появились.
Но сегодня не смог воспроизвести эксперимент - проект экспортировался без сабмодулей, так же как у вас. Он даже .gitmodules не сгенерил.
Вариант с указанием относительных путей, решает проблему лишь частично, т.к. в итоге пользователю нужно будет руками клонировать сабмодули и сложить их в правильном месте. В принципе можно для этого написать shell скрипт.
Надеюсь разрабы fast-export что-нибудь придумают.

Прочитал вашу ссылку про относительные пути - да, похоже это должно сработать. Надо проэкспериментировать.

Провел эксперимент - да с относительными путями все работает.
Потом при клонировании с удаленного репо так же нормально забираются сабмодули.

С данным исправлением https://github.com/frej/fast-export/pull/189 решается проблема с субмодулем cmake_obs_packages, который был удален в разное время из .hgsub и .hgsubstate. При преобразовании с этим исправлением после конверссии git submodule update --init --recursive работает без проблем.

Оперативно сработали :-)