Mercurial: с чего начать внедрение и зачем нужны патчи

в 10:44, , рубрики: Mercurial, патчи, Системы управления версиями, метки: , ,

   Как ни странно, но среди программистов ещё довольно много тех, кто не видит смысла в системах контроля версий (СКВ) или попросту не знает о них. Хватает и тех, кто знает, но не в курсе с чего начать внедрение или, при использовании, проходят мимо очень удобных возможностей.
   Когда-то давно, потеряв очередной архив с новой версией своей программы, наткнулся на удивлённый взгляд заказчика и вопрос: «В смысле нету? Но мы же заплатили вам за эту работу.» В тот момент я и сам о них ничего не слышал, но так как это был далеко не единичный случай в организации, то в итоге был освоен subversion. Через какое-то время, из-за характера работы (частые разъезды и необходимость работы с исходниками в командировках в разных местах) было решено перейти на mercurial, который позволяет иметь полную копию репозитория, работать с ней, как с полноценным основным репозиторием (хотя это понятие условное, основным он назначается, чтобы избежать путаницы) и не имел тех ограничений и проблем, которые на тот момент были у svn (невозможность в какой-то момент получить правильную рабочую копию нужной ревизии и зависимость от центрального репозитория). Mercurial на Linux оказался прост в освоении и удобен в использовании.
   После освоения и внедрения оставалось только сочувствовать соседнему отделу, где до сих пор царит хаос, не смотря на то, что нам удалось уже и там привить СКВ. Правда, в текущий момент это больше зависит от людей, которые как раз не видят смысла в таких системах.
   Думаю стоит сказать также, что СКВ позволяет отлаживать программы быстрее из-за того, что всегда можно достать предыдущую ревизию исходников, где не было ошибки и легко и быстро посмотреть какие изменения с того момента произошли. В идеале ревизии должны быть небольшими, чтобы поиск был быстрее.

   С чего стоит начать внедрение mercurial?
   Когда разработчик один, такого вопроса не возникает. Скачал, установил, разобрался, пользуешься.
   Если коллектив небольшой, то, при отсутствии понимания со стороны рядовых работников, делается на добровольно-принудительной основе указом сверху или долгим просвещением снизу. При наличии понимания всё получается само.
   В большом коллективе сочетается всё описанное выше. Только стоит помнить, что при большой теме, в которой участвуют все, нежелание использовать СКВ приводит к увеличению времени разработки и возможной потере средств. Потому приходится даже убеждать заказчика в том, что передаваемые ему исходники должны храниться с использованием контроля версий, дабы его весомое слово повлияло на излишне окрепшие умы.
   Начать стоит с выделения человека (небольшой группы), который будет следить за основным репозиторием и вносить в него все правки. Остальные должны это делать только через этого человека/группу. При этом, группа «хранителей» должна быть достаточно компетентна, чтобы увидеть нестыковку с идеями хранимого ПО и, конечно же, все изменения кода должны быть приведены к состоянию, в котором они без накладок могут быть занесены в репозиторий. Само собой, люди, следящие за репозиторием, должны знать СКВ не хуже остальных, но как минимум — чтобы выполнять свои обязанности. Также они могут обучить остальных в случае непонимания.
   Чтобы пояснить зачем это нужно, приведу пару примеров.
   Как-то, приехав в командировку, посмотрел репозиторий, который хранился там (он как раз считался основным) и увидел замечательную ревизию с описанием из спецсимволов, иероглифов и пр. нецензурщины. Оказалось, что эти изменения туда внесли люди, которые не очень в этом разбираются и которых такие мелочи, как неправильная кодировка текста, не волновали. Но при этом понять, что же там были за изменения и кто их внёс после этого стало невозможно. Откатить их также возможности не было (возможность на самом деле есть, но затратная по времени и усилиям).
   Также не раз доводилось видеть убитые насмерть репозитории, из которых вообще ничего нельзя было достать, т.к. пользователь, вносивший изменения, испортил структуру коммитов. Да чего уж, и сам иногда портил, пока изучал. Правда, в основном копии. Потому для охраны целостности данных нужен знающий человек.

   Про то как пользоваться mercurial`ом и команды рассказывать не буду, т.к. на их сайте полно документации.

   Зачем нужны патчи в mercurial?
   Патчи очень сильная и неоднозначная возможность mercurial.
   Изначально hg имел возможность вносить изменения только коммитами (commit), которые нельзя было исправить после внесения в репозиторий, кроме последнего, его можно было откатить назад. Но только один. Со временем появилось расширение mq, которое позволило создавать патчи, похожие на обычный коммит, но изменяемый. Т.е. патч — это набор изменений от последнего коммита/патча, который можно поправить.
   В это сила и слабость одновременно. Сила этого в том, что если забыл что-то, опечатался, не заметил ошибку, то это можно исправить прямо в этом изменении. Патч[и] можно отослать через чат/icq/jabber/e-mail и т.д., т.к. по сравнению со всей программой он небольшой. Тут можно сказать, что существует т.н. bundle, т.е. кусок репозитория между двумя коммитами, но зато патч можно просто открыть и посмотреть/оценить, потом исправить, при необходимости, а bundle нет.
   Слабость патчей в том, что чем их больше, тем больше вероятность накосячить с их сохранением в репозитории. Или при исправлении самого старого патча в очереди может понадобиться правка всех остальных, на которые эта правка может повлиять.
   Отсюда можно сделать выводы:
       — использование патчей улучшает вид репозитория, т.к. позволяет ужать кучу коммитов с исправлениями своих изменений в один, за счёт того, что патч можно править;
       — патч удобно пересылать из-за маленького размера, что может сэкономить деньги и время;
       — патч нежелательно делать большим (как и коммит), т.к. при этом затрудняется поиск ошибки в нём;
       — патч можно легко открыть и посмотреть изменения в нём любым текстовым редактором/просмотрщиком;
       — патчей в очереди не должно быть много (желательно не больше 7-10, потом с ними становится неудобно работать), после набора критической массы и готовности их нужно перевести в коммиты (hg qfinish);
       — как и с любым коммитом, ПО с патчем должно как минимум компилироваться и крайне желательно запускаться (хотя это, конечно, необязательно, но позволит избежать неприятных моментов при попытках запустить ПО какой-либо ревизии);
       — при должном знании и осторожности патч можно править прямо в файле патча, но при этом он не должен быть наложен на рабочую копию;
       — желательно коммиты и патчи делать логически завершёнными;
       — хорошая идея в патче/коммите делать однострочный заголовок (не больше 70 символов), отражающий всю суть изменений и через пустую строку уже писать развесистый комментарий с пояснением — что и зачем было сделано в патче. Это поможет разобраться, например через год, что же там было сделано разработчику или тем, кто его сменит, а также удобно будет смотреть сокращённый и полные логи ревизий.

   В конце хочется добавить, что mq входит в пакет mercurial, а также туда входит и расширение hgk, которое позволяет при наборе соответствующей команды (hg view) вывести окно, где можно увидеть дерево ревизий и изменения, которые в них делались, что очень удобно. Патчи там отмечены так, чтобы было заметно, что это не коммиты. Все расширения нужно прописывать в конфигурационном файле .hgrc.

   Пока это всё. Возможно кому-то поможет.

Автор: huankun


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js