TLDR: Сделал набор скриптов автоматизации миграции Bitbucket репозиториев с Mercurial на Git.

В один непрекрасный день мой любимый хостинг репозиториев Bitbucket объявил о скором прекращении поддержки репозиториев Mercurial в пользу Git, после чего все Mercurial репозитории будут удалены.

Предыстория

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

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

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

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

В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):

1. Первое поколение
   
   • SCCS (Source Code Control System)
   • RCS (Revision Control System)
2. Второе поколение
   • CVS (Concurrent Versions System)
   • SVN (Apache Subversion)
3. Третье поколение
   • Git
   • Mercurial

По мере увеличения числа вовлечённых в проект людей возникает необходимость как-то более эффективно организовывать и управлять их деятельностью. На начальном этапе для этой цели использовались Google-таблицы, но их возможности ограничены, и появилось желание перейти на новый уровень. Изучение доступных систем управления проектами показало, что из систем с открытым кодом Redmine наиболее продвинутая и по некоторым показателям обгоняет даже проприетарные системы.

Redmine, действительно, обладает большими возможностями: управление несколькими проектами, отслеживание ошибок, интеграция с репозиториями, перекрёстные ссылки на исправленные баги в коммитах и на коммиты в баг-репортах, назначение разных ролей пользователей в каждом проекте и т.д. Однако процедура установки довольна сложна, а для некоторых очень полезных функций требуется небольшая доработка или использование плагинов. Надеюсь, что предлагаемое ниже руководство поможет желающим использовать Redmine в своих проектах.

Один из принципов дизайна в Atlassian — лаконичность. В ходе эволюции UX некоторые непопулярные действия, расчитанные на опытных пользователей, были спрятаны в выпадающих списках или за горячими клавишами. Там они ждут предприимчивого пользователя, который случайно наткнётся на них благодаря случайному нажатию клавиш или клику мышки (ну, или заглянет в руководство). Вот шесть моих любимых трюков Bitbucket Cloud, о которых вы, возможно, никогда не слышали:

Омнибар

Омнибар в Bitbucket — это строка быстрого доступа к действиям, похожая на ⇧⇧ в средах разработки JetBrains или ⌘+P в Sublime Text. Запустить омнибар можно на любой странице, нажав клавишу точки.

По умолчанию, он покажет набор действий, соответствующих текущему контексту:

Когда я познакомился с Mercurial, то все свои знания я почерпнул из статей Спольского (перевод на Хабре), которые подробно описывают основные принципы работы Mercurial и ежедневную работу с ним. Долгое время я использовал Mercurial в пределах, которые не превышали объема этих статей. Наверно, для одиночного разработчика этого почти достаточно. Почти. Но Mercurial сегодня значительно шире и обладает возможностями допускающими редактирование истории изменений, наличие которых, в общем-то, не очевидно, хотя возможности эти достаточно ценны. А из комментариев к разным статьям по системам управления версиями видно, что многие разработчики об этих возможностях не знают. Ниже я хочу провести обзор ряда возможностей Mercurial связанных с изменением истории.

О чем пойдет речь:

• фазы
  
• hg commit –amend
  
• hg strip
  
• hg rebase
  

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

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

Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).

Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

К сожалению, нам не удалось найти полноценного русскоязычного мануала по работе с современными системами контроля версий. Собрав информацию из разных статей и англоязычных видео на YouTube, мы решили сделать своё собственное руководство, которое:

1. Будет пошаговой инструкций (по ней же будут работать наши программисты).
2. Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат — работающую распределенную систему контроля версий).
3. Будет работать с использованием только графических интерфейсов (причины см. выше).

Как‐то понадобился мне просмотр списка файлов в удалённом репозитории. Клонировать его при этом как‐то не очень хотелось. Поиск в интернете ожидаемо дал множество ответов вида «это невозможно, делайте клон». А мне‐то надо всего‐навсего убедиться, что по некоторой ссылке находится репозиторий, соответствующий некоторому архиву с исходными кодами. Так как «некоторая ссылка» находится на странице с описанием содержимого этого архива (точнее, дополнения в этом архиве), то мне показалось достаточным сравнить только список файлов. Как быть?
Конечно, Mercurial не предоставляет практически никаких возможностей работы с удалённым репозиторием. Точнее, можно сделать push и pull (ну и clone как частный случай последнего). Но можно ли сделать pull, не затрагивая при этом файловую систему? Ответ: можно, здесь нам поможет hg incoming. Собственно, алгоритм работы такой:

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

Краткий список того, о чём пойдёт речь в статье:

• hg serve (hgweb) — встроенный веб-сервер
• расширения pager, progress и color
• hg [c]record — выбор отдельных изменений для коммита
• revsets и filesets — поиск коммитов и файлов с запросами любой сложности
• hg evolve — Changeset Evolution или же «изменяемая история»

Некоторое время назад в компании, где я работаю в связи с расширением комманды было принято решение о введении процесса code review. Выбор инструмента пал на Review Board — продукт обладает достаточным функционалом, активно разрабатывается с 2006 года и является open source. В качестве системы контроля версий у нас используется Mercurial

О том, с чем какими задачами столкнулись при организации процесса код ревью для связки Review Board + Mercurial — под катом.

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

Привет, сообщество!

В честь 1 миллиона своих пользователей сервис Bitbucket.org предлагает купить лимитированную серию футболок со своим брендом со скидкой 50% на дочернем сервисе компании AtlassianSwag. Стоимость такой футболки $20. Сервис (bitbucket) даёт купон на скидку $10 при приглашении в репозиторий новых пользователей.

Сегодня на свой электронный ящик я получил приглашение на участие в конкурсе от Bitbucket. В нём говорится, что сервис репозиториев Bitbucket достиг порога в 1 миллион пользователей, в связи с чем устраивается конкурс с главным призом — поездка на хакатон в Сан-Франциско.

Мое первое знакомство с системой контроля версий было еще в школе. Это был Subversion. В то время меня очень впечатлила его сила и возможности. Но шло время. Были не очень приятные моменты с переименовыванием файлов, каталогов и прочее (да, да здравствует svn 1.5, 1.6 и его вечные папки .svn). И все бы продолжалось в том же духе, если бы однажды в компании не задумались о смене системы контроля версий. Все случилось неожиданно быстро и предо мной возник Mercurial. Пришлось почитать о его особенностях, поспрашивать советов бывалых и вот я уже сам помогал своим коллегам разобраться в поведении и работе нового инструмента. Чем дольше я знакомился с Hg, тем больше он мне нравился, точнее, нравился его децентрализованный подход к контролю версий, Subversion же неизбежно отходил на второй план.
Однако, на новом месте работы мне снова пришлось вспомнить о Subversion, что, честно сказать, меня не обрадовало. К счастью, это не было безоговорочной политикой компании и предложить альтернативу было вполне реально, особенно учитывая, что некоторые сотрудники предпочли Git и успешно с ней работают. Значит, дело за малым – наглядно показать, в чем же преимущества работы с децентрализованными системами контроля версий: Git или Mercurial, но, в силу моего личного опыта, рассказать я решил про Hg. Собственно, эта статья есть краткое содержание круглого стола, проведенного мной с целью сравнения и смены системы контроля версий.

18 марта Скотт Гатри в своем блоге анонсировал очередные нововведения в облачную платформу Windows Azure. Представленный новый функционал включает в себя:

• HTML5-клиенты (CORS) для Windows Azure Mobile Services, включая доступ из популярной библиотеки PhoneGap;
• улучшенная поддержка Windows Phone 7.5, новые библиотеки и пакет Nuget;
• поддержка размещения веб-сайтов из Mercurial (Bitbucket, Codeplex) и Dropbox;
• новые шаблоны в Web Sites;
• публичный доступ к сервису HDInsight – облачной платформе Hadoop как сервис.

Ниже о этих нововведениях чуть подробнее.

Поддержка HTML5/JS-клиентов и PhoneGap в Mobile Services

Windows Azure Mobile Services предлагает облачную инфраструктуру для всех популярных мобильных платформ: Windows 8, Windows Phone, iOS и Android. В текущем обновлении к поддержке мобильных платформ добавилась поддержка веб-клиентов на HTML5/JS, в частности популярной библиотеки PhoneGap. Теперь вы можете получить доступ ко всем данным сохраненным из мобильных клиентов через код написанный на HTML5/JS.

На прошлой неделе Fog Creek объявила об окончании войны между Git и Mercurial. Точнее, проанонсировала таким экстравагантным образом выпуск Kiln 3.0 с поддержкой одновременной работы с репозиториями через Git или Mercurial.

Kiln это онлайн-хостинг Hg и Git репозиториев с продвинутой системой code review и управлением группами проектов и пользователей. В связи с новым релизом и провокационным утверждением по поводу войны DVCS, да и тем, что Kiln не очень широко представлен на Хабре, стоит упомянуть несколько ключевых моментов.

Например, что бесплатная версия Kiln не ограничена по времени если у вас до 2х пользователей…

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, или других особых телодвижений, вся магия происходит на сервере.

С какой целью и для кого

Данная статья является кратким изложением основных преимуществ DVCS.
Я собрал воедино все доводы о пользе перехода на DVCS (а именно mercurial) и постараюсь доступно изложить это для тех у кого не было практического опыта работы ни с одной из DVCS.

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.