Какие проблемы могут возникнуть при ветвлении в системе контроля версий?

Не могли бы вы предложить статью, книгу или доклад на конференции о возможных проблемах, с которыми группа разработчиков программного обеспечения может столкнуться при ветвлении в среде контроля версий? Мы создаем сводку для одного из наших спонсоров, и нам нужно процитировать респектабельные источники информации. Пока что я нашел короткие обзоры Криса Бирмеле и Эрик Синк.

Заранее спасибо!

пс. В статье Шаблоны ветвления для параллельной разработки программного обеспечения Appleton et. Аль выглядит фундаментально, но довольно старым.


branch version-control
person yegor256    schedule 12.07.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Как упоминалось в Bliki Мартина Фаулера, у FeatureBranch может быть проблема с семантическими конфликтами .

alt text

Проблема, о которой я больше всего беспокоюсь, - это семантический конфликт.
Простым примером этого является то, что если профессор Плам изменяет имя метода, который вызывает код преподобного Грина.
Инструменты рефакторинга позволяют безопасно переименовать метод, но только на основе вашего кода. Итак, если G1-6 содержит новый код, вызывающий foo, профессор Плам не может сказать об этом в своей кодовой базе, поскольку у него его нет. Вы узнаете только о большом слиянии.

Переименование функции - относительно очевидный случай семантического конфликта. На практике они могут быть гораздо более тонкими. Тесты являются ключом к их обнаружению, но чем больше кода для слияния, тем больше вероятность возникновения конфликтов и тем сложнее их исправить.
Это риск конфликтов, особенно семантических конфликтов, которые страшно делать большие слияния.

См. Пример семантических конфликтов в этом вопросе SO.

Как только это будет принято во внимание, вам также необходимо различать CVCS и DVCS (централизованный или распределенный VCS), поскольку DVCS привносит ортогональное измерение в ветвление: "публикация" (push / pull в / из удаленных репозиториев, что означает, что вы можете работать с «той же» веткой, оставаясь в полной изоляции, потому что вы работаете в локальном клонированном репозитории).
CVCS, такие как SVN, имеют свои собственные проблемы с слияние ветвей, в котором DVCS должна быть очень хороша.

См. Также «Когда следует разветвляться?»

person VonC    schedule 12.07.2010

arrow_upward
0
arrow_downward

Взгляните на Hg Init - там подробно объясняется, почему ветвление очень проблематично в определенных случаях и как решить эту проблему. . Ключевым моментом является то, что ветвление вообще не проблема, но обратное слияние изменений на разных ветвях может занять много времени.

person sharptooth    schedule 12.07.2010

arrow_upward
0
arrow_downward

Извините, я не могу найти ссылку на настоящее утверждение, но я помню, как Ларри Маквой что-то сказал в строки «вы никогда не хотите, чтобы ветви умножались, вы всегда хотите снова объединить ветви вместе». Чем дольше ваши ветки остаются невыполненными, тем больше вероятность того, что изменения в одной будут конфликтовать с изменениями в другой. Функциональные ветки - ваши друзья, но я рекомендую извлекать изменения достаточно часто, чтобы быть в курсе изменений морального эквивалента «магистрали» или «восходящего потока», и не забудьте объединить ветки обратно в «ствол» или «восходящий поток», как только их потребность удовлетворена.

Возможно, более лаконично: я всегда считал полезным определять время жизни ветки перед ее созданием. Знайте, зачем вы создаете ветку, как долго она просуществует, когда вы решите объединить ее или выбросить.

person sarnold    schedule 12.07.2010