2010-02-27

Критика VersionControlTools Фаулера

Добрейшего.

Перефразирую советскую классику: "А не замахнуться ли нам на Мартина нашего, понимаете ли, Фаулера?". Ну, просто набрел сегодня на свежую статью от означенного автора и зацепил меня заголовок "VersionControlTools". Да, в оригинале тоже слитно, Вики уже прям надиктовывает названия статей.

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

1. Рассуждая о стОящих системах контроля версий, автор не заморачивается ознакомлением с большинством из имеющихся. Для рассмотрения берутся традиционные SVN, git, Mercurial. Про остальные говорится, что в них нет или capability, или visibility. Т.е. остальные или хиленькие, или малораспространённые. Кто же попадает в эти категории? В первую очередь, IBM Rational ClearCase и Microsoft Team Foundation Server ("Two in particular generate a lot of criticism"). В сад также отправляются Perforce, Bazaar и MS VSS (этого - поделом, надо сказать). Причина?
I will, at least for the moment, leave it with the fact that developers I respect have worked extensively with, and do not recommend, these products.
"Пацаны сказали - западло". Точнее, "Пастернака не читал, но осуждаю". Ну и ещё автор слышал о каких-то просто bizarre вещах, которые вытворяли разрабочики, используя эти тулы. Ну прям отбивает желание не то что пробовать эти системы, но даже даже читать про них, не правда ли?

2. Далее идет выбор между централизованной и децентрализованной (распределенной) моделью. Или вам нужна централизация,тогда SVN - ваш выбор, или децентрализация - тогда будет ещё одна развилка - git/Hg. Далее идет разбор плюсов и минусов обеих моделей. Точнее даже не моделей, а просто SVN и всего DVCS. Причем после короткой прилюдии у Subversion рассматриваются только минусы: распределенные системы быстрее на операциях с локальным репозиторием, они могут эффективно работать без наличия сети... И ещё один минус: оказывается, в распределенных системах вы можете гадить в локальный репозиторий сколько угодно и весь этот стыд не будет никому доступен, пока вы сами не выдадите его миру... а в SVN - все видно, даже те ветки, код на которых строиться не будет (увидят - засмеют!). В общем, первые 2 причины засчитываются, третья является просто следствием странного представления о стыде и его видимости.


3. Отдельно автор остановился на ветвлении (branching). По его мнению
... the argument against a DVCS, that it encourages wanton branching, that feels good early on but can easily lead you to merge doom.
Т.е. развратное ветвление приводит к непонятно хаосу во время слияния (merge doom).

Причем!
... reckless branching isn't something that's particular to one tool. I've often heard people in ClearCase environments complain of the same issue.
Т.е. необоснованное бранчевание - это прям беда многих тулов и поговаривают, что в КлирКейсе та ж самая задница!

Что тут скажешь... многие команды вообще только-только начинают понимать, что отращивание бранчей - это хорошо и этого не надо бояться. А тут уже 2 шага вперед - все так и норовят сделать лишний десяток веток, по рукам не успеваем давать! В общем, странное заявление. NB: Ветвиться можно и нужно.
К слову, о ClearCase. Там ветвление вообще делается почти прозрачно для пользователя. Достаточно в правилах текущего представления репозиториев сказать - "при чекауте вот этих элементов автоматически создать ветку такую-то и сделать эту ветку рабочей для указанного элемента". Что и происходит. Девелопер лишь делает чекаут элемента - автоматом создается ветка и работа идет уже на ней. Причем таких автоветок можно делать любое количество и их содание будет происходить прозрачно.
Reckless, говорите... ну-ну...

4. Далее идет сравнение распределенных Hg и git. Тут встреча проходит на равных, в конце мачта - ничья, а Mercurial выигрывает по буллитам... ну, просто Фаулер использует именно его и всё тут. Принципиальных отличий нет.

5. Предлагается рассмотреть вариант с использованием сразу двух систем контроля версий. Конечно, упоминается git-svn. Делается вывод, что иногда можно и так, особенно если начальство навязывает одну систему, а команда подпольно юзает что-то другое, сливая в навязанную систему лишь большими кусками. В общем-то, был у нас подобный пример на одном проекте - использовали SVN и ClearCase... Я там не работал, но разработчикам нравилось. А сколько было геморроя интегратору... это знает только он. Хотя, человек тварь живучая, ко всему привыкает и даже начинает получать от неудобств особенное удовольствие.

По мне - так на здоровье, хоть 3 системы. Главное тут - как это организовать, а ещё важнее - как поддерживать в работающем состоянии, без отката к хаосу.

6. Ну и под конец следует вывод, ради которого можно было и не читать всю статью, а проскроллить вниз, ибо истину говорит:
often its the practices and workflows that make a bigger difference
Т.е. неважно, какой инструмент ты используешь, главное - использовать его правильно, эффективно и желательно по прямому назначению.

В целом, вся статья - много слов о простых истинах и собственных домыслах.


Сухой остаток: ничего нового; читать рекомендую только ценителям истинного SCM (при наличии иммунитета), евангелистам DVCS и фанатам Фаулера.

6 комментариев:

  1. >В общем, странное заявление. NB: Ветвиться можно и нужно.

    Тут смысл немного другой, как мне кажется
    1) Недостаток DCVS в том, что они поощряют ветвление
    2) Хотя необдуманно ветвиться можно в любом средстве, в том же Clear Case
    3) И все таки DCVS таки поощряют ветвление, что требует повышенной квалификации от команды.

    Заявление как раз вполне выдержанное, если мы ведем речь про такие agile-практики, как CI/TDD/Scrum и т.д.

    Смысл CI как раз в том, чтобы интегрироваться с trunk как можно чаще, постоянно запуская интеграционные тесты. Здесь как раз лучше работать прямо в trunk, делая, однако, ветки, по необходимости, когда задача относительно долго пребывает в "разобранном" состоянии.

    Т.е. нужно учитывать, что Мартин излагает с колокольни agile.

    И я с ним полностью согласен в этом плане.

    Опять таки - с другой колокольни открывается другой вид, и требуются другие практики, там, Feature Branch + выделенный интегратор. Важно понимать область действия практик и не критиковать с одной колокольни другую, практического смысла в этом не сильно много.

    ОтветитьУдалить
  2. Ну во-первых, автор пытается судить о бОльшей части систем контроля с чужих слов, что есть очень плохо.

    Во-вторых, то, что ветвление плохо, потому что есть CI и потому что в нём ветки не нужны - из текста не совсем ясно. От про CI чуть подробно говорит буквально в одном абзаце, отсюда впечатление, что автор просто против и всё.

    В общем, однобокая статья. Надеюсь, в статье про FeatureBranch раскроется по-полной.

    ОтветитьУдалить
  3. >Во-вторых, то, что ветвление плохо, потому что есть CI и потому что в нём ветки не нужны - из текста не совсем ясно.

    Когда пишут "надо ветвиться" тоже ведь не ясно, что у них нет CI ;)

    >В общем, однобокая статья

    Но ведь других-то нет. Над схваткой еще никто не поднялся, в духе Лукьянова - пока есть Светлые и Темные, а место Инквизиции - вакантно.

    Все в основном хвалят ту или иную практику, но мало говорят про границы ее применения.

    ОтветитьУдалить
  4. > Все в основном хвалят ту или иную практику, но мало говорят про границы ее применения.

    Кстати, да. Не встречал ничего такого - у всех какие-то крайности. Вот, например про RUP недавно пост был у меня - тоже ничего себе система, применима при любом масштабе вроде как. Ан нет, на практике народ хочет чего попроще.

    ОтветитьУдалить
  5. >Во-вторых, то, что ветвление плохо, потому что есть CI и потому что в нём ветки не нужны - из текста не совсем ясно.

    Ну почему же не нужны, это ведь тоже крайность.

    Основное разногласие, как я понимаю, не в самих ветках - см FeatureBranch, там у него таки все работают в своих ветках - а в критерии возможности их "сброса" в trunk.

    Чем "тяжелее" проект и методология, чем больше численность команды, тем суровее критерии. И наоборот, при малых командах и "легких" методологиях все максимально упрощается, вплоть до прямой работы на trunk-е. Главное, чтобы все компилировалось и проходило хотя бы базовые unit-тесты.

    ОтветитьУдалить
  6. Да, в целом согласен - чем строже входной контроль перед транком, тем больше вероятность использования веток.

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