Просмотр исходного текста страницы The Risks of Distributed Version Control

<blockquote>
Перевод статьи [http://blog.red-bean.com/sussman/?p=20 {{PAGENAME}}] выполнен сообществом компании [http://www.custis.ru «Заказные ИнформСистемы»].
</blockquote>

Да, забавно, как времена меняются. 
Когда мы начинали разрабатывать [[Subversion]] пять лет назад, 
[[CVS]] был огромным злобным монстром, которого мы хотели «низвергнуть».

Сегодня, хотя [[Subversion]] есть ещё куда развиваться, он уже достиг критической массы в мире свободного ПО.
Список рассылки «users@» насчитывает тысячи подписчиков и стал самоподдерживаемым.
Каждая достаточно крупная свободная операционная система поставляется с относительно новой версией <tt>Subversion</tt>.
В книжных магазинах есть небедный выбор книг о <tt>Subversion</tt>.
Десятки крупных проектов, таких как 
[[RuPedia:KDE|KDE]], [[RuPedia:Apache|Apache]] и [[RuPedia:GNU Compiler Collection|GCC]] перешли на него.
Вы уже не удивляетесь, когда вы встречаете проект с открытым исходным кодом, использующий <tt>Subversion</tt>,
ведь <tt>SVN</tt> стала стандартным выбором «по умолчанию» для большинства новых проектов.

А сейчас, приколитесь, появилось целое новое поколение систем контроля версий на горизонте: 
* [[EnPedia:GNU_arch|arch]], 
* [[EnPedia:codeville|codeville]], 
* [[EnPedia:Monotone (software)|monotone]], 
* [[EnPedia:Bazaar (software)|bazaar-ng]], 
* [[EnPedia:SVK|svk]],
* [[RuPedia:git|git]], 
* [[RuPedia:mercurial|mercurial]].

И эти новички — распределённые системы контроля версий (''DVCS'', ''Distributed Version Control Systems'') — хотят «подсидеть стариков».
Да, вы не ослышались: <tt>Subversion</tt> сейчас «Старик».
Интересно, когда это произошло? :-)

Это новое поколение систем в корне отличается тем, что доводит идею «изолированных операций» до крайности.
У каждого пользователя на локальном компьютере хранится полная копия репозитория, т.е. <tt>100%</tt> истории проекта.
Каждый человек фактически сам по себе.
Пользователи соединяют свои репозитории между собой как только им угодно
и меняются изменениями как коллекциями марок, 
а система автоматически отслеживает, какие «чужие» изменения у вас отражены, а какие — нет.

Что-то свежее и самоутверждающее в этом конечно есть, 
ведь это явно расширяет традиционную централизованную модель [[CVS]] и [[Subversion]].
Конечно, в каком-нибудь проекте может быть решено, что один выделенный репозитарий является главным,
а все остальные участники, должны отправлять и получать изменения через него, как и в централизованной модели.
Но проекты могут быть организованы в более интересные формы:
древовидную иерархию репозиториев, кольцо репозиториев
или даже просто произвольно связанный граф, что безусловно, весьма гибко.

Однако сторонники этих систем немного фанатичны в «превосходстве» DVCS над нынешними
централизованными системами.
Снова и снова я слышу подобные панегирики:
«Круто! Если я хочу реализовать новую функциональность, мне вообще не нужно иметь доступ на фиксацию изменений, ведь у меня есть моя личная копия репозитория, и я могу независимо творить и фиксировать новый функционал в своем личном репозитарии, так часто, как мне нужно, пока окончательно не завершу доработку. 
Вот тогда то я все остальным и представлю.»

Звучит как «счастье всем даром, и никто не уйдет обиженным», но мне это видится в более мрачных тонах.
Смотрите, что хочет сделать этот счастливчик — уползти в пещеру,
неделями в одиночку корпеть над сложной функциональностью, 
а затем воткнуть «вылизанное» решение в «основной ствол» проекта.

И именно это поведение весьма вредно для open-source сообществ, где все должны:
* работать совместно;
* согласовывать общие цели;
* обсуждать архитектуру и непрерывно просматривать работу друг друга.

В нашем Subversion-сообществе такое поведение мы именуем «сбрасывание бомбы», и считаем
антиобщественным и даже аморальным.
Ведь обычно, получаемая таким образом новая функциональность настолько велика и сложна, 
что её почти невозможно рецензировать.

А если её сложно рецензировать, то её сложно внедрить в основной ствол проекта,
сложно поддерживать как качество кода, 
так и саму эту функциональность для всех, кроме, возможно, самого автора.
И в таких случаях мы, за редким исключением, ругаем автора за «затворничество».

По-хорошему, надо сначала обратиться к сообществу, с предложением-проектом, 
и после некоторого обсуждения мы 
* либо просим разработчика творить последовательно, серией небольших доработок; 
* либо выделяем отдельную «ветку» в репозитории.

И действительно, на самом деле им не нужен доступ на применение к основному коду, 
а все, что им нужно — отдельная ветвь.
При этом, сколь угодно много других участников могут просматривать самые мельчайшие изменения, 
причем, в порядке их поступления, обсуждать, давать советы и другие отзывы 
и тем самым поддерживать рабочий цикл разработчиков.

Т.е. основная цель — не быть застигнутым врасплох большим изменением в коде.
Это помогает сообществу концентрироваться на общих целях, при этом держит его в курсе достижений каждого.
И хотя многие говорят: «Классно, что я могу разветвить целый проект без ведома остальных!»,
на это я постоянно твержу: «Ну ёлки-палки, ну почему вы не работаете вместе с остальными?
Почему вы не просите о доступе для фиксации изменений?».
Это типичная проблема, которую нужно решать не техническими, а социальными методами:
проектам следует активно поощрять стороннюю работу небольших команд и без промедления давать возможность заводить частные ветки.

Я, вероятно, говорю как Мистер «Противник-распределенных-систем-контроля-версий», но на самом деле это не так.
Определенно, они удобны и вполне хороши.
Просто я думаю, что их нужно применять с большой осторожностью потому,
что предоставляемые ими удобства также способствуют проявлениям
социально-обособленного поведения, которое вредно для сообществ open-source разработчиков.

[[Category:Статьи о Subversion]]

== Ссылки ==

Больше информации по этому вопросу вы найдете в [http://web.mit.edu/~ghudson/thoughts/bitkeeper.whynot эссе] Грега Хадсона (Greg Hudson) — оно и заставило меня первоначально обратить внимание на эту проблему.

Также по этой теме есть отличная книга Карла Фогеля (Karl Fogel) [http://www.producingoss.com/ «Producing Open Source Software»].

Всё это — вопросы правильного развития и управления сообществ разработчиков открытого ПО.


{{replicate-from-custiswiki-to-lib}}