ADD-2010: отчет Игоря Беспальчука/Круглый стол про системы контроля версий

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

"– Ты сюда зачем пришел, обсудить проблему или просто пофлеймить?? – Ну, вообще-то.. просто пофлеймить." (Диалог в президиуме круглого стола)

Круглый стол проходил в аудитории, очень неплохо оснащенной технически. На длинном столе – индивидуальные экраны и микрофоны, плюс экраны в торце зала. На все экраны транслировалось изображение с экрана ноутбука Стаса Фомина, который в online-режиме строил mind-map обсуждения (думаю, уже все видели, на что этот процесс похож, Стас регулярно это делал на встречах Agile Russia).

Впрочем, организация круглого стола на этом заканчивалась. Экраны есть, mind-map есть, а в остальном – «каждый сам за себя». В результате круглый стол по большому счету проходил в одном его углу, где собрались несколько наиболее активных участников конференции, знакомых между собой. Это уже упомянутые Олег Царев, Кирилл Корецкий, а также Андрей Аксенов, человек, известный как автор поискового движка Sphinx. Время от времени высказывались (причем очень неплохо высказывались) и другие участники, но этой троицы звучало больше всего Может быть, даже слишком много.

Обсуждали в основном Subversion, Bazaar и Git, а также массу смежных тем (типа LaunchPad vs GitHub). Не хочу долго рассказывать про банальные выводы типа «для каждого сценария использования – свой инструмент, кому-то и CVS с SourceSafe будет лучше».

Что же интересного было сказано по сути? Отпишу по пунктам, что мне показалось новым и интересным.

Ветки в Subversion

Про ветки в SVN говорили много и с жаром, примерно так:

«– Они вообще не работают! – Нет, работают. Это они так работают. – Ну, знаете, предупреждать надо! У меня проект! – У всех проект. Проверять инструменты надо.»

Речь о том, что в SVN действительно была объявлена важная функциональность в версии 1.5, но выяснилось, что работает она очень странно. Если вы сделали ветку, вносите в нее изменения (B), в это время в основном стволе также производятся изменения (A), то вы можете командой –reintegrate-branch влить изменения A в ветку. Но когда вы попытаетесь влить изменения B из ветки обратно в остновной ствол, SVN попытается применить к нему не только изменения B из ветки, но и изменения A, хотя в основном стволе они уже есть. Эта ситуация будет диагностирована как конфликт.

Мы сталкивались с такими проблемами в RMS, и пришли к тому, что все-таки слияние- исключительно ручная операция.

Но утверждается, что с версии 1.5.4 (или 1.6) Subversion стал в этом отношении лучше и теперь правильно выполняет слияние веток. Это стоит проверить детальнее и четко знать, на что способен наш инструмент контроля версий, а на что – нет.

Git и fetch & rebase

Оказывается, в мире Git очень популярна стратегия «fetch & rebase». Представители других религий крутят пальцем у виска, но git'овцы довольны.

Эта стратегия заставляет разработчиков искусственно линеаризировать все изменения в основном стволе продукта, упрощая (противники говорят – «искажая») историю изменений в ветках. Суть стратегии в том, что взяв однажды для работы некоторую ревизию репозитория, разработчик вносит какие-то изменения, а затем фиксирует их обратно в репозиторий, но таким образом (rebase), что они обязаны примениться к текущему, последнему, изменившемуся его состоянию. И в истории изменений эти фиксации видны не как параллельные изменения, которые затем кому-то нужно сливать, а как единая линейная последовательность изменений. При высоком уровне автоматизации причина и автор ошибок находится методом бинарного поиска (с прогоном тестов на разных ревизиях).

Эту стратегию и git в целом защищал Иван Сагалаев – человек из Яндекса, который произвел на меня исключительно хорошее впечатление (в отличие от наиболее активных участников конференции).

В кулуарах мы пообщались также на эту тему с Андреем Бибичевым, и он сказал, что для него fetch & rebase – тоже совершенно новое знание, но что ему эта идея страшно понравилась.

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

Несколько мнений

Записал несколько экспертных мнений, относительно которых у меня самого пока нет четкой позиции.

1. Если вам не нужен fetch & rebase и вы боитесь сломать историю изменений, но хочется иметь распределенную систему контроля версий – берите Mercurial.

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