Критика 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 и фанатам Фаулера.