Как ни странно, но среди программистов ещё довольно много тех, кто не видит смысла в системах контроля версий (СКВ) или попросту не знает о них. Хватает и тех, кто знает, но не в курсе с чего начать внедрение или, при использовании, проходят мимо очень удобных возможностей.
Когда-то давно, потеряв очередной архив с новой версией своей программы, наткнулся на удивлённый взгляд заказчика и вопрос: «В смысле нету? Но мы же заплатили вам за эту работу.» В тот момент я и сам о них ничего не слышал, но так как это был далеко не единичный случай в организации, то в итоге был освоен 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
