Используйте Subversion без транка

Question

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

Кто-нибудь еще делает это?

Если да, то заметили ли вы плюсы / минусы?

Даже если ваша команда этого не делает, у кого-нибудь есть мысли по поводу этого макета?

Answer 1

Вы говорите о рекламной модели . В статье Perforce освещаются проблемы, связанные с ней - информирование о смене ролей строк кода и перемещении работы между филиалами.

Расширение моих взглядов на перечисленные проблемы:

1) Изменение политики строк кода:

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

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

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

например. Ствол:

• любой разработчик может совершить
• любое изменение
• модульные испытания должны пройти
• проверка кода после коммита

Версия ветки:

• только разработчик обслуживания
• только исправление ошибки
• модульный тест + регрессионные тесты
• проверка кода 2 другими разработчиками перед коммитом

Метка ветки:

• нет коммитов после создания

Частная ветка разработчика:

• Только разработчик регистрирует
• Любые изменения
• Тестирование необходимо только до слияния с магистралью
• Проверка кода перед слиянием с транком

Если у вас есть модель продвижения, то у вас есть одна политика во время основной разработки, а затем нужно сообщить всем, когда вы изменяете политику во время подготовки к выпуску, затем другую политику (для строки кода) после освобождения строки. 1065 *

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

Если вы посмотрите на разработку ядра Linux, вы увидите разницу между моделью Promotional и моделью Trunk: дерево Линуса является Promotional - оно проходит циклы между окном слияния и периодом rc / стабилизации. Но Linux-next и -mm выросли, чтобы получить более магистральную линию.

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

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

2) Переезд:

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

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

Answer 2

Моя проблема с бумагой Perforce заключается в том, что она отбрасывает рекламную модель, не упоминая главное преимущество - сокращение накладных расходов на слияние. На самом деле, в документе ошибочно утверждается, что «основная модель» не предусматривает «никаких дополнительных административных накладных расходов», что является нелепым утверждением. Модель «всегда объединять в магистраль» означает только это - у вас есть накладные расходы, связанные с объединением каждого. Это бесполезно, если у вас есть следующая ситуация (которая у нас есть):

a) небольшая команда (от 5 до 7 разработчиков), все в пределах досягаемости друг от друга. общение не является проблемой, когда нам нужно сделать ветку

и

b) кодовая база, где на самом деле есть только 2 основные ветви - производственная ветка и «следующая вещь в разработке». Может быть, однажды в голубой луне у нас будет 3.

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

Answer 3

Я недавно начал работу над проектом, который находится в хранилище Subversion. Кто бы ни создавал репозиторий, он не следовал какой-либо конкретной компоновке - он просто вставлял все в корень репозитория (без ствола /, без ветвей / и, конечно, без тегов /). Я хотел создать ветку для работы и некоторые теги для других вещей, но понял, как трудно это сделать в репозитории Subversion, который не следует правильной компоновке.

Answer 4

Subversion допускает оба подхода. Ствол не является необходимостью, но конвенция. Если он у вас есть, некоторые инструменты работают легче (например, инструменты миграции для Git). Если у вас его нет, вы должны сделать что-то вручную, но я не могу придумать, что вы заметите во время своей повседневной работы.

Answer 5

IME, в некоторых средах ствол является хорошим местом для обмена исправлениями и изменениями в / из. То есть все объединяют свои исправления с стволом, и все объединяют исправления других с ствола. Мы обнаружили, что это очень полезно в среде, где большое количество кода распределяется между многими независимыми проектами и где все эти проекты вносят вклад в общий код.

Однако ваша среда может отличаться.

Answer 6

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

У нас это хорошо работает, но в нашем проекте много подпроектов.