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

Question

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

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

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

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

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

Edit:

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

• альфа: функциональность А.
• бета: функциональность A + B.
• гамма: функциональность A + B + C.

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

Изменить 2, после ответа TridenT:

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

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

Answer 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)-------->

Вот твой сундук!

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

Это напоминает мне о стабильном - тестировании - нестабильном версиях от Debian .
Ваша модель идеально подходит , если она представляеткак вы работаете.

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