Нужна ли магистраль в многоверсионных проектах

#svn #version-control #project-management

#svn #контроль версий #управление проектами

Вопрос:

Я работаю в проекте с одной выпущенной версией в обслуживании и двумя или более версиями в разработке одновременно.

Вот тут-то и возникают сомнения в необходимости магистрали.

Я прочитал книгу SVN в Read Bean и другие (Pragmatic Version Control with Subversion), и все они предлагают использовать режим разработки, ориентированный на магистраль. Я не знаю, применимо ли это в моем случае и существуют ли другие проекты с многоверсионным циклом выпуска, которые успешно используют другие схемы.

Почему рекомендуется режим, ориентированный на магистраль? Есть ли какие-либо проблемы с ветвями версий, все более удаляющимися от магистрали? В этой схеме интеграция с магистралью имеет какой-либо смысл?

 /-----гамма-----/(3)---------->
 / /
 /----бета---/(1)---/(2)--/--- бета-версия--------/--
 / / / 
 /------------ альфа--/------/--- 
 /  
------------магистраль--------------------( a)----------------------( b)------------------>

Редактировать:

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

  • альфа: функциональность A.
  • бета-версия: функциональность A B.
  • гамма: функциональность A B C.

Это означает, что вся функциональность ветки включается в более поздние ветки (посредством синхронизации слияний). Ветви отличаются уровнем стабильности (старые ветви более стабильны) и функциональностью (у молодых ветвей новая функциональность).

Редактировать 2, после ответа TridenT:

Разработка стабильной версии выполняется в ветке магистрали, а затем объединяется обратно в магистраль, когда она стабильна, поэтому магистраль содержит все стабильные изменения и, в конечном итоге, более стабильную версию программного обеспечения.

Я задаю этот вопрос сейчас, потому что я переосмысливаю стратегию ветвления всего проекта.

Комментарии:

1. Можете ли вы объяснить, как это может быть возможно: «две или более версий в разработке одновременно». Вы действительно говорите о новых версиях программного обеспечения или о функциях, над которыми работают несколько команд?

Ответ №1:

Я собираюсь взять вашу диаграмму и немного ее реорганизовать:

                                           /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--
              /           /      /                          
     /------------alpha--/------/---                        
    /                                                        
------------trunk--------------------(a)----------------------(b)------------------>
  

Сначала удалите trunk , поскольку вы ее не используете. Да, вы объединяетесь обратно в магистраль, но вы никогда не извлекаете из нее код. Вместо этого beta берется из alpha и gamma происходит от beta . С таким же успехом можно было бы сэкономить все эти усилия, сливаясь обратно в строку кода, которую вы никогда по-настоящему не используете:

                                           /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/
              /           /      /                      
     /------------alpha--/------/                    
    /                                      
trunk
  

Теперь давайте выровняем вашу диаграмму, чтобы основная линия разработки была красивой и прямой:

 trunk-alpha-------beta-----------------------gamma-------------------------->
                       /      /                       /
             ---alpha-/------/         ---beta-------/
  

И, наконец, переверните все…

              /-alpha------            /--beta-------
            /                        /               
trunk------/--(beta)----------------/-(gamma)---------------(gamma)-------->
  

Вот ваша магистраль!

Я знаю, что вы делаете. Вы не кодируете на магистрали, потому что предполагается, что магистраль представляет ваш релиз. На вашей исходной схеме есть две версии магистрали. Точка (a), где вы объединяете альфа-ветвь обратно в магистраль, и точка (b), где вы объединяете бета-ветвь обратно в магистраль. Это представляет ваш альфа-релиз и бета-версию.

Однако именно для этого и существуют теги! Вы создаете тег для выпуска, и ваш тег теперь представляет ваш выпуск. И это лучше, потому что тег сохраняет историю вашего файла.

Допустим, вы переходите к своей магистрали в точке (b) и берете журнал определенного файла. Вы видите файл в точке (b), и вы видите другую версию в точке (a). Но вы понятия не имеете, как этот файл был изменен между точками (a) и (b). На самом деле, вы даже не знаете, чей релиз отвечает за конкретное изменение.

Однако, если бы вы сделали тег из ветки вместо того, чтобы объединять свой код обратно в магистраль, вы бы увидели всю историю этого файла вплоть до самой первой версии файла. Команда Subversion log (если вы не используете --stop-on-copy переключатель) перенесет вас от тега вниз к бета-версии ветви и обратно к магистрали.

Ах, скажете вы, но как я могу увидеть различия между альфа-версией и бета-версией? В моей схеме я могу посмотреть историю магистрали!

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

Итак, у вас действительно есть магистраль, но вы просто не называете ее так.

Комментарии:

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

2. Я попытаюсь перепроектировать стратегию ветвления, чтобы магистраль стала настоящей магистралью. Спасибо.

Ответ №2:

Потребность в парадигме магистрали (или, в мире git, devel) — это в основном потребность в точке, где встречаются передовые разработки (ветви функций) и меры контроля качества (ветви выпуска). Она служит общей основой для всех активных ветвей, которые в основном определяются через их отличие от магистрали.

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

Хотя альтернативные модели часто кажутся поначалу хорошими, люди часто на собственном горьком опыте убеждаются, что более одной постоянной активной ветки смертельно опасны для командной коммуникации. Преимущество магистрали в том, что любой член команды, разрабатывающей функцию, может отделиться от магистрали, развиваться, слиться с магистралью и быть счастливым. При наличии нескольких активных ветвей вам придется объединиться в несколько ветвей или пострадать от разветвления функциональности со всей плохой отладкой и поддержкой пользователей. Это основная причина для принятия схемы магистрали. Винсент Дриссен написал великолепную статью об этой модели разработки, которая применима и к SVN, как только вы замените ветку devel на магистраль.

Похоже, что вы действительно следуете схеме магистрали в своем проекте. Ваши молодые ветви (гамма в примере) на самом деле являются магистралью проекта, потому что они получают новую функциональность. Более старые ветви (альфа и бета) получают исправления ошибок, которые позже объединяются в ветку, которую вы назвали магистралью. Однако, поскольку вы никогда больше не разветвляетесь от магистрали, а только от gamma, слияния из alpha и beta не нужны. Магистраль, похоже, обладает наименьшими возможностями и наибольшей стабильностью (самая старая ветвь), что противоречит обычной логике магистрали.

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

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

Комментарии:

1. Мы работаем способом, аналогичным статье Винсента Дриссена, на которую вы ссылаетесь: у нас есть ветка рабочей версии, где вносятся, стабилизируются и выпускаются более срочные изменения, затем эти изменения объединяются в магистраль. В то же время существуют другие ветви магистрали с другим уровнем функциональности (будущие производственные версии), которые в будущем станут ветвью производственной версии. Эти ветви обновлены с помощью магистрали, чтобы получить стабильную функциональность.

Ответ №3:

Это напоминает мне о стабильном — тестируемом — нестабильном управлении версиями из Debian.
Ваша модель абсолютно корректна, если она отражает способ вашей работы.

Магистрально-ориентированный имеет одно преимущество: независимо от того, сколько у вас ветвей, магистраль обычно является последней стабильной версией в текущей разработке.

Комментарии:

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

2. @thiton: Да, ты хорошо это объяснил, лучше меня 😉 Спасибо за ваш комментарий.

3. Дело в том, что в нашем проекте концепция магистрали именно такая: более стабильная версия программного обеспечения. Разработка стабильной версии выполняется в ветке магистрали, а затем объединяется обратно в магистраль, когда она стабильна, поэтому магистраль содержит все стабильные изменения и, в конечном итоге, более стабильную версию программного обеспечения.