The Risks of Distributed Version Control

Ссылки сюда (2) →

Перевод статьи The Risks of Distributed Version Control выполнен сообществом компании «Заказные ИнформСистемы».

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

Сегодня, хотя Subversion есть ещё куда развиваться, он уже достиг критической массы в мире свободного ПО. Список рассылки «users@» насчитывает тысячи подписчиков и стал самоподдерживаемым. Каждая достаточно крупная свободная операционная система поставляется с относительно новой версией Subversion. В книжных магазинах есть небедный выбор книг о Subversion. Десятки крупных проектов, таких как KDE, Apache и GCC перешли на него. Вы уже не удивляетесь, когда вы встречаете проект с открытым исходным кодом, использующий Subversion, ведь SVN стала стандартным выбором «по умолчанию» для большинства новых проектов.

А сейчас, приколитесь, появилось целое новое поколение систем контроля версий на горизонте:

• arch,
• codeville,
• monotone,
• bazaar-ng,
• svk,
• git,
• mercurial.

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

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

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

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

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

И именно это поведение весьма вредно для open-source сообществ, где все должны:

• работать совместно;
• согласовывать общие цели;
• обсуждать архитектуру и непрерывно просматривать работу друг друга.

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

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

По-хорошему, надо сначала обратиться к сообществу, с предложением-проектом, и после некоторого обсуждения мы

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

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

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

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

Ссылки

Больше информации по этому вопросу вы найдете в эссе Грега Хадсона (Greg Hudson) — оно и заставило меня первоначально обратить внимание на эту проблему.

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

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

---

Репликация: База Знаний «Заказных Информ Систем» → «The Risks of Distributed Version Control»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».