Переход с Mercurial на GIT в Atlassian Bitbucket с сохранением файлов в кириллице

    Предыстория


    Ещё летом в официальном блоге BitBucket опубликовали запись, в которой сообщили об окончании поддержки репозиториев Mercurial.

    Прекращение поддержки Mercurial будет проходить в два этапа:

    1. С 1 февраля 2020 года пользователи больше не смогут создавать новые репозитории.
    2. С 1 июня 2020 года пользователи не смогут использовать функции Mercurial в Bitbucket или через его API, а все репозитории Mercurial будут удалены.

    С причинами такого решения всё более-менее понятно, но я в работе использую несколько репозиториев на Mercurial (Mercurial мне всегда больше нравился, но этот вопрос я оставлю за рамками данной статьи), которые потребовалось сконвертировать в GIT.

    Собственно, на этом месте началась…

    Проблема


    Разработчики и служба поддержки BitBucket предложили несколько вариантов такой конвертации, я их всех перепробовал, а заодно попробовал сторонние инструменты, наподобие импорта репозиториев в GitHub.

    Выяснилось, что все эти инструменты портят имена файлов и каталогов, которые содержат символы в кириллице, а у меня полно таких файлов (ТЗ, спецификации и прочие подобные файлы). Забавно, что комментарии к коммитам, содержащие кириллицу, прекрасно переносятся и отображаются после переноса.

    В просторах интернета находил информацию о том, что в Mercurial есть инструменты (ключи в конфиг-файле репозитория), которые позволяют управлять кодировкой символов по умолчанию, но во-первых, они включаются только явно, а во-вторых, нет инструмента преобразования существующего репозитория. Ну и я не проверял, насколько эта опция помогает с миграцией при помощи готовых инструментов — мне уже поздновато этим путём идти.

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

    Возможно, кому-то перенос репозитория с русскими символами в именах файлы тоже актуален и моя статья сэкономит немного времени.

    Решение


    Базовая процедура


    1. Забрать себе репозиторий git@github.com:seewindcn/tortoisehg.git — в нём есть плагин fixutf8, которого нет в основной поставке. Далее предполагается, что локальная копия будет находиться в каталоге D:\Development\tortoisehg
    2. Сделать копию своего репозитория Mercurial, чтобы не повредить основное местоположение. Далее все команды выполняются в каталоге копии.
    3. Выполнить исправление имен файлов и каталогов командой D:\Development\tortoisehg\hg.exe addremove -s 100
    4. Сделать коммит в репозиторий D:\Development\tortoisehg\hg.exe commit -m «Fix filenames»
    5. Включаем плагин hggit — в фале .hg\hgrc нужно добавить
      [extensions]
      hggit =
    6. Готовимся к преобразованию в GIT — создаем метку master командой D:\Development\tortoisehg\hg.exe bookmark -r default master
    7. Создаем GIT репозиторий в BitBucket
    8. Делаем коммит в репозиторий hg push git+ssh://git@bitbucket.org:<user>/<reponame>.git (внимание, тут используется штатный hg, потому что клон от seewindcn не хочет работать по SSH)
    9. Проверяем на сайте BitBucket, убеждаемся, что имена файлов кириллические не сломались
    10. Клонируем GIT репозиторий к себе, проверяем имена файлов, выполняем побайтовое сравнение всех файлов, сборку проекта, тесты
    11. После сборки наверняка появится масса новых файлов, которые GIT предложит закоммитить. Файл .hgignore придётся руками сконвертировать в .gitignore. К счастью, это можно сделать один раз и использовать один файл для всех остальных репозиториев.

    В результате удалось основную ветку default исходного репозитория Mercurial перенести со всей историей коммитов в master репозитория GIT и даже с метками. Из минусов отмечу только полное отсутствие информации об изменениях файлов с кириллицей в истории коммитов — коммиты есть, а от файлов с кириллицей нет даже упоминаний (остальные файлы, естественно, в полном порядке).

    В целом, задачу можно было считать выполненной, но из спортивного интереса, мне также было интересно перенести остальные ветки.

    Перенос веток, кроме default


    1. Получить список веток hg branches
    2. Для каждой ветки
      1. Переключиться на ветку hg up <branchname>
      2. Cоздать метку (имя метки не должно совпадать с именем ветки): hg bookmark -r <hgbranchname> <gitbranchname>
      3. Залить ветку в GIT hg push git@bitbucket.org:<user>/<reponame>.git

    Может случиться так, что имя ветки тоже будет содержать кириллицу, в этом случае hg branches покажет кракозябры. В этом случае я использовал визуальный hg workbench — переключался на ветку и создавал метку там.

    На этом месте наступает полный феншуй.

    На случай, если кому-то будет интересно покопать поглубже, то оставляю…

    Список использованной литературы


    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 11

      +1

      На самом деле, что в Git, что в Mercurial, с кодировкой имён файлов под Windows всегда были проблемы.


      Простой опыт. Попробуйте закоммитить файлы под Windows, а потом склонировать на Linux. Или в обратную сторону. Все не LATIN символы будут покорёжены.


      Так что если над проектом работают люди из разных OS, то только английская кодировка. Увы...

        +1
        Случай с разными операционками я морально ещё как-то готов принять, могут быть проблемы с допустимостью символов, с регистром этих символов. Но не полностью — UTF8 и в Африке UTF8. Попробую, кстати, на виртуалке проверить, как себя поведут сконвертированные репозитории.
          +2
          Проверил под Debian, файлы отображаются корректно. Там может быть момент, связанный с содержимым (cr/cr+lf), но это давно научились решать.
            0

            А вот это уже действительно интересно...

          +2
          Проблема в том, что в битбакете кроме собственно содержимого mercurial-репозитория, может быть и другая информация, например, тикеты. У меня были такие проекты на mercurial с многолетней историей. Если пересоздавать проект с GIT-репозиторием, то все это потеряется. В конце концов, Atlassian могли бы предоставить инструмент конвертирования mercurial репозиториев в git, чтобы проекты оставались неизменными. Но они это не сделали. Видимо, посчитали нерентабельным и нецелесообразным. Ну и я тоже посчитал дальнейшее пребывание у них нерентабельным и нецелесообразным и несмотря на то, что у меня был у них платный аккаунт с 2007 года, перенес свои проекты на self-hosting на базе RhodeCode
            0
            Справедливости ради, Atlassian и GitHub предоставляют такой инструмент, но, как я понимаю, из-за старой проблемы с кириллицей именно в Mercurial, кириллические файлы стандартными инструментами ломаются.

            Касательно тикетов — тикеты я перенёс из встроенного инструмента BitBucket в Jira и мне этого хватило — они интегрируются по номеру тикета в описании коммита, после переезда Mercurial->Git ссылки работают.

            Ну и self-hosting не панацея, если производитель движка (тот же RhodeCode или BitBucket Server) решит забросить поддержку одного типа репозитория, то придётся либо переезжать, либо застревать на неподдерживаемой версии движка.
              +2
              self hosting очень похож на панацею Хотя бы потому что ничто не мешает оставаться на старой версии пока не напишется инструмент конвертирования. А с битбакетом вообще некрасиво получилось. Они метлой выгоняют всех пользователей меркуриала без возможности остаться. И вроде пользователей меркуриала всего 1 процент но это сотни разработчиков и тысячи репозиториев.
                0
                Self Hosting — это оттягивание решения на чуть более долгий срок. Потому что клиенты тоже развиваются, может статься, что придётся иметь два клиента — один для своих репозиториев, второй для сторонних (флиланс/доступ к опенсорсам в облаке). Ну и вопрос правки багов/безопасности тоже остаётся. К примеру, работа с https сейчас прогрессирует, закрываются старые tls 1.0 и 1.1, и это, наверняка, не конец. Может статься, что пропатченная операционка не даст подключиться к серверу с исходниками. СУБД, опять же, придётся старую в продакшене держать… В общем, много вариантов, где это может выскочить.

                Эмоционально — да, я согласен, что уход от Меркуриала неприятен, но с точки зрения бизнеса это верное решение. У меня был вариант раньше переехать полностью на Гит, но бизнес-решение было остаться. Чуть ниже — некоторые из причин.

                Касательно победы Гита над Меркуриалом — тут не во всём понятное для меня явление. По всем тестам, которые публиковал Битбакет, Меркуриал работал быстрее. И в плане бытовом он мне больше нравился (сложнее «запороть» репозиторий, чуть понятнее функционал). В общем, как первая распределенная система контроля версий в жизни начинающего программиста, он, на мой взгляд, лучше. Но это уже холивар и оффтопик ;)
                0
                К сожалению инструмент GitHub у меня «не пошел» не только с кириллическими файлами, но и со всеми кириллическими комментариями…
                Скрин
                image
                  0
                  Жесть. У меня комменты выжили. Метод из статьи не пробовал? Мне любопытно, насколько универсальное решение получилось :)
                    0
                    завал на работе, особо пробовать/разбираться некогда было, с наскока не вышло, пока отложил

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое