Kiln Harmony — Mercurial + git в одном репозитории

    Fog Creek – компания созданная Джоелом Спольски и, возможно, известная вам по продукту Trello, на прошлой неделе представила свой новый проект державшийся долгое время в тайне: Kiln Harmony. Это хостинг Mercurial (hg) и git репозиториев. К сожалению, исключительно платный, есть только 45 дней пробного периода. В чём же новость, спросите вы, если Mercurial + git хостинги уже есть на рынке и, в том числе, бесплатные, как Bitbucket.org? Особенность Kiln Harmony в том, что один репозиторий на хостинге одновременно является и Mercurial и git репозиторием! По заявлениям разработчиков великий холивар закончен и теперь вы можете соредоточиться на кодинге, а не на выборе системы контроля версий. Push и pull в единый репозиторий размещённый на Kiln Harmony из вашей любимой системы контроля версий (Mercurial или git) не требует установки отдельных расширений, типа hg-git, или других особых телодвижений, вся магия происходит на сервере.

    А магии там на самом деле много.

    image
    Для начала, при работе через web вы заметите переключатель «Показывать как в Git» или «Показывать как в Mercurial». В большинстве интерфейсов, таких как просмотр самих файлов или диффов, отличий нет. Нюансы появляются при просмотре subrepositories и submodules.

    image
    Ветвление – особый вопрос, так как именно в подходе к веткам у Mercurial и git больше всего различий. Однако, команда Fog Creek поставила своей целью не менять привычки пользователей. Работаете вы с Mercurial или с git – вы не должны помнить о каких-то особенностях другой системы и перестраивать свой привычный рабочий процесс.

    Если ваш репозиторий достаточно прост и имеет только одну ветку — в этом случае всё прозрачно: git master синхронизируется с Mercurial tip.

    Если в git репозитории несколько branches, то в Mercurial они превращаются в bookmarks – это решение также очевидно и в большинстве холиваров (в т.ч. на хабре) не раз обсуждалась, что git branch = hg bookmark.

    Магия начинается при попытке транслировать ветки в обратную сторону из Мercurial в git. Во-первых, в Mercurial есть анонимные ветки без уникального имени бранча или букмарка, что в git выглядит не очень хорошо. Во-вторых, в Mercurial есть так называемые “named branches”, которые совсем не похожи на git branch и аналога в git нет. Статья для саморазвития: Mercurial: руководство по созданию веток. Для решения этой проблемы ребята из Fog Creek поступили хитро — всем анонимным веткам автоматически присваиваются bookmarks и соответсвенно начинает работать схема git branch = hg bookmark. А Mercurial «named branches» транслируются в git refs (знающий читатель сразу заметит, что при таком подходе в лоб возникнет потеря информации, но более подробное описание тонкостей алгоритма выходит за рамки этой обзорной статьи).

    Итак, значит ли это, что если я всю жизнь работал с Mercurial и не использовал bookmarks, то теперь я должен буду их изучить, т.к. они автоматически начнут появляться на всех анонимных ветках? Ответ – нет! Магия происходит автоматически где-то на сервере. Причём вы можете пользоваться старой версией Mercurial, которая даже не поддерживает bookmarks.

    Более подробно о других нюансах и их технической реализации можно прочитать в отдельной статье в блоге разработчиков: Detailed articles on exactly how Kiln Harmony works. Кроме того, все желающие приглашаются на сессию вопросов и ответов 19 марта: Kiln Harmony Live Q & A.

    Личный взгляд.

    Я активный пользователь Mercurial и пассивный пользователь git (git повсюду, иначе никак!). Когда-то в начале своего пути я мечтал о таком сервисе, пробовал hg-git и прочие извращения. На мой взгляд обе системы имеют свои плюсы и минусы. Конечный выбор в наше время больше зависит от конкретной команды разработчиков и от рабочего окружения, а не от тех или иных уникальных функций, которых не так уж и много. Если вы владеете git и попали в команду где вынуждены использовать Mercurial – проще выучить Mercurial, и наоборот. Это под силу любому техническому специалисту и займёт не очень много времени, а в будущем сэкономит гораздо больше сил и средств при общении с коллегами. Так что сервис вряд ли полетит, к тому же за 25$ в месяц на пользователя.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 26
    • +14
      Даже не представляю, кому это понадобится.
      • 0
        Я думаю, к примеру, тем, кто сомневается, что выбрать: hg или git. Такой сервис может сделать переход между этими системами намного менее болезненным
        • +5
          … и тем, у кого есть лишние 25$ в месяц
          • 0
            Jira тоже не бесплатна, а покупают же!
            • +6
              У Jira есть некая волшебная лицензия «10$ за 10 пользователей» — так что если ставить на свой сервер то это для небольших команд по факту бесплатно — дешевле кружки сейчас, увы, даже не очень хорошего пива. Версия, хостящаяся у них будет уже 10$ в месяц — но это тоже за 10 пользователей и в целом фаально недорого.
              • 0
                Как правило даже в небольшой софтверной конторе кол-во человек больше 10. А когда смотрим на цену когда больше 10 человек, то становится интересней. Эта цифра выбрана ими не спроста ;)
                • +5
                  А для конторы в более чем десять человек, в которой более чем десять человек уже активно пользуются джирой, цина в пару тысячь долларов не кажется такой запредельной :).

                  Это я не то чтобы джиру рекламирую, хорошие альтернативы есть. Это я к вопросу о популярности. Либеральные лицензии для опен сорса / небольших команд + возможность в полтора клика установить собственный локальный сервер = автовин.
                • +3
                  На днях буквально смотрел в очередной раз на ее лицензии, и посчитал, сможем-ли мы вписаться в 10 пользователей. При 4-6 активных разработчиках, 2 тестерах, и 2-4 манагеров, и нескольких сторонних товарищей, которым тоже нужно предоставить доступ хотя-бы для чтения — уже плохо вписываемся. Хотя, конечно, при таком раскладе должны быть деньги на нормальную лицензию… но пока экономим $100 в месяц и пользуемся Redmine.
                • +3
                  Джира обычно привносится не усилиями команды разработчиков, а откуда-то из района management'а/начальства, которому надоедает хаос и хочется чуть больше порядка.

                  Убедить начальство, что отдавать (на коллектив из 10 человек) 90 тысяч рублей в год ради того, чтобы 5 человек могли _НЕ_ учить git/hg будет сложно.
                  • +1
                    >>а откуда-то из района management'а/начальства
                    Не всегда и не везде. Иногда и в команде работающей по Agile-практикам, там ребята сами приходят к решению какие им нужны инструменты.

                    >>_НЕ_ учить git/hg будет сложно
                    Не в этом дело! Я вот до последнего буду сопротивляться решению юзать git. Потому что пользуясь им в течении полгода понял, что больше такого не хочу. После перехода на Mercurial я понял, что с ним буду работать еще долго, пока в мире систем контроля версий не произойдет очередная революция. Вот скажите мне зачем на работе нужна ситуация, когда несколько человек друг другу доказывают какая CVS лучше?
                    • +1
                      Просто для понимания: если вы не в замке из слоновой кости обитаетесь, придётся работать и с hg, и c git'ом. Потому что в современной экосистеме разработки часто бывает нужно заслать коммит/pull-реквест в «альтернативную» систему версий, которую точно под вас переделывать не будут.
                      • 0
                        И зачастую проще базово освоить вторую систему, чем разбираться с нюансами расширений типа hg-git.
                • 0
                  45 дней бесплатно должно хватить, чтобы выбрать.
                  • 0
                    Слабо себе представляю IT компанию, у которой нет лишних $25 на качественный сервис с плюшками, даже если эта плюшка нужна одному разработчику.
                  • 0
                    Согласен, не зачем сомневаться и давно пора ставить Mercurial.
                    Как видите холивар начать слишком просто, а на работе надо работать, а не холиварить. Если Klin будет прозрачным как для лагеря Git, так и для лагеря Mercurial, то это реально круто!
                    • 0
                      Адепты git весьма пассионарны, к сожалению. А тем, кто задумывается над адекватностью своих инстументов, было бы весьма полезно внимательно прочитать статью с техническими подробностями и подумать, какое из отображений было сделать проще и почему. И еще подумать, почему пользователи mercurial довольно редко используют букмарки.
                      • 0
                        У адептов git есть мощный аргумент в виде github.
                        • 0
                          Ну, я за них рад, правда. Гитхаб не поддерживает бесплатные приватные репозитории, поэтому рассматриваться как конкурент bitbucket-у может только в некоторых ситуациях. По сути для коммерческого проекта в обоих случаях (hg и git) реальный инструмент один и тот же — bitbucket. Ну а в остальном отличаются они (github и bitbucket) друг от друга не очень значительно и чем дальше, тем меньше.
                          • 0
                            Ну как сказать, что только один. Допустим фирма делает коммерческий форк свободного проекта хостящегося на гитхабе и время от времени посылает багфиксы. Затраты на аккаунт гитхаба могут быть сильно меньше необходимости интегрировать две системы (вернее четыре даже). Или библиотеку/фреймворк, хостящиеся на гитхабе может использовать.

                            Да и субъективно, как человек, у которого постоянно открыты и битбакет (и часть репозиториев на гит) и гитхаб, могу сказать, что гитхаб по функциональности превосходит битбакет, хотя hg нравится больше чем git. Но для закрытых эксперимнтов в последнее время все чаще стал использовать репы гит на битбакете именно из-за вопросов интеграции с интересующими открытыми проектами.
                            • 0
                              Ну да, сценарии, когда выгоднее использовать github, придумать можно. Непонятно только, насколько часто они реализуются, такие сценарии. По моему опыту в коммерческих проектах хорошо, если не начнут насиловать SVN-ом с особым цинизмом. А уж до тонкостей преимуществ github-а тем разработчикам как-то вообще фиолетово обычно, им ветки создавать, пушить изменения и писать нормальные комментарии и то лень.
                • –7
                  А svn?..
                  • +8
                    Для значительной части применений проигрывает как mercurial, так и git — так что для новых проектов, если нет специфический задач вроде содержания в репозитории терабайт графики, применять subversion бессмысленно. Удел subversion — legacy и спецкейсы, где мы вынуждены использовать клиент-серверную архитектуру.
                  • +6
                    Вообще-то проект называется Kiln (а не Klin) Harmony
                    • +4
                      До сих пор не поправлено, даже в ссылках так (yawn).
                      UPD: Даже в тэгах (facepalm)
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • +1
                        А еще есть HgLab.

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

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