BenderBot: 1 версия

2009-06-30T15:43:37Z

1 версия

StasFomin: оформление

2009-06-30T11:06:09Z

оформление

WikiSysop: 1 версия

2008-09-03T16:33:11Z

1 версия

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

2008-09-03T16:29:58Z

Новая страница

<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> сейчас «Старик».
Интересно, когда это произошло? :-)

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

Что-то свежее и самоутверждающее в этом конечно есть,
ведь это явно расширяет традиционную централизованную модель [[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}}

← Предыдущая	Версия 15:43, 30 июня 2009
(нет различий)

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

← Предыдущая	Версия 16:33, 3 сентября 2008
(нет различий)

The Risks of Distributed Version Control - История изменений

BenderBot: 1 версия

StasFomin: оформление

WikiSysop: 1 версия

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