суббота, 20 марта 2010 г.

Джоел и Subversion, Mercurial, Git. Действительно антибиотик?

Progg it
Недавно в блоге Джоела Спольски была опубликована последняя статья – «Distributed Version Control is here to stay, baby», по крайнее мере сам Джоель называет её последней. Статья, как понятно из заглавия посвящена распределенным системам контроля версий. После прочтения статьи возникло желание немного её прокомментировать. Сначала я выложу краткий обзор содержания, при этом постараюсь не упустить важных моментов. Делать полноценный перевод нет ни времени, ни желании. Итак, Джоел пишет следующее…
В распределенных системах контроля версий их распределенность не является самой интересной особенностью. Наиболее интересным является изменение модели – распределенные системы контроля версий работают с изменениями (changes), а не с версиями. Если централизованная система контроля версий «думает»: у меня есть версия 1, после этого будет версия 2, после этого версия 3 и так далее. В распределенной системе все по другому: сначала не было ничего, потом добавлены эти изменения, потом добавлены те, и т.д. Изменение программной модели должно изменить модель пользователя. Теперь пользователю тоже придется мыслить в терминах изменений. Если раньше было: «Я хочу получить версию номер Х», или «Я хочу последнюю версию», то теперь: «Хочу получить набор изменений Пети».
Это смена парадигмы! Именно поэтому, когда вы переходите с Subversion на Mercurial, у вас вроде бы все получается, но вас новая система все время расстраивает, вы не можете к ней привыкнуть, и начинаете её ненавидеть. Только когда вы начнете мыслить в терминах «изменении», и выбросите из головы «версии» все встанет на свои места. Именно изменение модели работы системы контроля версий привело к существенному упрощению слияния (merge) кода. И соответственно к более активному использованию ветвления, использованию его там, где оно необходимо. Теперь можно не думая о сложностях последующего слияния создавать долгоживущие ветви для команд тестирования и поддержки и создавать короткоживущие ветви для экспериментов.
Если вы все еще используете SVN – перестаньте. Mercurial и Git – это антибиотики. Теперь существуют технология лучше.
И, вы знаете, я с Джоелом согласен почти полностью. Джоел смог объяснить то, что понимает каждый, кто освоился в распределенных системах. Но не каждый сможет выразить это словами. Это действительно смена основной концепции системы контроля версий, и именно из-за этого DVCS так туго входят в коллективы программистов. Наблюдаю это на личном опыте. Все привыкли мыслить категориями Subversion, и как только человек видит новую ветку в репозитории, даже ту, которая по идее скоро сольется с основной – он почему то пугается.
Продолжая пугаться, и не совсем понимая основных принципов системы, человек продолжает делать коммиты «раз в сутки», вместо того, чтобы делать коммиты по необходимости, по завершению каждой связной частички.
Однако распределенные системы контроля версий – это отнюдь не антибиотики. Главная проблема, как и всегда, в головах. И без решения этой проблемы никакой Hg, Git или Bazaar не спасет. Да, они гораздо больше соответствуют workflow разработки ПО, и большинство действий в этих системах легко объясняется логической необходимостью и разумностью. Но способов выстрелить себе в ногу в них значительно больше, хотя они и не очевидны. Наблюдал однажды картину, когда 4 разработчика постоянно работали каждый в своей ветке – в этом случае никакая смена парадигмы контроля версий не поможет.
Распределенные системы контроля версий – это отличная вещь, это действительно шаг вперед, который открывает каждому разработчику новые возможности и новую функциональность. И это действительно происходит за счет смены модели взаимодействия, Джоэл, безусловно, прав. Но, мне кажется, воспринимать их как серебряную пулю неправильно. Они избавляют от значительной части головной боли связанной с контролем версий, ветвлениями и слиянием. Однако от кривых рук они все равно не вылечат. Поэтому все равно необходимо нормально разбивать задачи, думать головой, и мержиться не раз в месяц с десятком изменений в каждом файле от каждого автора. Тут уж никакой Mercurial не спасет.

2 комментария:

  1. Mercurual это действительно отличная DVCS, мне тоже нравиться. Кстати появился русскоязычный форум про Mercurial http://groups.google.ru/group/ru_hg

    ОтветитьУдалить
  2. Не знаю, по мне, так и в SVN можно (и полезно) было мыслить изменениями, а не только состояниями.

    А насчёт "отдельного долгоживущего бранча у каждого разработчика" - я начинаю приходить к мысли, что в hg это один из наиболее разумных подходов: каждый сидит в своей песочнице, регулярно делает merge default, а когда песочница пришла к рабочему состоянию - из неё вливается всё в default.

    Иначе при нормальном подходе (когда прямо в default не коммитим, только мержим бранчи после того, как они будут доделаны - чтобы default всегда был готов к сборке) вроде получаем один из трёх вариантов:
    1. Не закрываем ветки вообще, просто вливаем в default. hg heads выдаёт кучу мусора. hg heads -t - полегче, но не показывает default
    2. После вливания веток в default закрываем их (hg up ветка, hg commit --close-branch). Лишняя ручная работа, а hg glog выдаёт нечто несуразное (особенно если так закрыть несколько старых веток - будет казаться, что именно они - bleeding edge). Вот тут http://stackoverflow.com/questions/2237222/how-to-correctly-close-a-feature-branch-in-mercurial у человека вроде как раз такая проблема.
    3. Закрываем ветки перед вливанием в default. Опять же лишяя ручная работа, о которой к тому надо не забыть + надо сообразить, что именно сейчас ветка закрывается окончательно.

    ОтветитьУдалить