Subversion - это багажник действительно лучшее место для основного развития?

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

Я совершаю что-то по ошибке
Когда ствол просто должен быть сломан из-за того, как работает SVN. Канонический пример - переименование файлов - вы должны перенять все переименования файлов и вносить дальнейшие изменения позже; однако переименование файла может потребовать рефакторинга кода для отражения пространства имен или изменения имени класса, поэтому вам в основном необходимо выполнить одну логическую операцию в два этапа. И сборка разбивается между этапами 1 и 2.

Я могу представить, что были бы инструменты, позволяющие предотвратить что-то по ошибке (например, TeamCity и отложенные коммиты), но можете ли вы действительно преодолеть вторую проблему? Если нет, не лучше ли было бы делать "дикое развитие" на какой-то ветки вроде /branch/dev и только сливаться с trunk, когда сборка достаточно прочная?

Ответ 1

Ваша соединительная линия должна ВСЕГДА скомпилировать, если вам нужно внести изменения, вы должны использовать ветку и объединить изменения позже.

Прочтите эту главу книги SVN: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

Ответ 2

Я бы рекомендовал прочитать эту статью статью о лучших практиках SCM.

Извлечен из статьи:

У вас есть магистраль. "Mainline" или "trunk" - это ветвь кодолина, которая эволюционирует навсегда. Основная линия обеспечивает конечный пункт назначения практически для всех изменений - как исправления технического обслуживания и новые функции - и представляет собой первичную, линейную эволюцию программного продукта. Сроки выпуска и разработки mainline и работа, которая происходит в ветвях, распространяется обратно на магистраль.

Изменить: я бы также рекомендовал читать SCM Patterns.

Ответ 3

Это действительно зависит от вашей среды. В некоторых случаях наличие временно отключенного ствола не является большой проблемой. Но если вы работаете с более чем 2-3 людьми, это, вероятно, не будет хорошей идеей.

В этом случае я думаю, что использование веток более свободно - хорошая идея. Их достаточно просто настроить и восстановить (если вы не позволите вещам слишком сильно не синхронизироваться).

Конечно, если все ваши разработчики используют одну и ту же ветку, вы на самом деле ничего не выиграете - у вас просто будет ваш телефон, называемый /branch/dev, но его нарушение будет по-прежнему серьезной проблемой! Разбивайте ветки так, чтобы на каждом из них работало только несколько разработчиков, и вы должны быть хорошими.

Ответ 4

Сундук - это место, где предполагается продолжение развития. У вас действительно не должно быть проблем с "сломанным" кодом, если каждый тестирует свои изменения перед их выполнением. Хорошим правилом является сделать обновление (получить весь последний код из репозиториев) после того, как вы закодировали свои изменения. Затем выполните сборку и выполните часть тестирования. Если все строит и работает, вы должны быть хорошо, чтобы проверить его.

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

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

Как Ханибал всегда говорил "A-Team": "Мне нравится, когда план объединяется".

Ответ 5

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

Кстати, даже если вы переименовываете файл, вам все равно разрешено его редактировать. Я делаю это все время.

Ответ 6

Я создал пару оболочечных скриптов, чтобы упростить создание ветвей ветвей развития:

# Create new branch and switch to it
function svn_bswitch()
{
   branch=$1; shift
   msg="$1"; shift

   URL=$(svn info . | sed -ne '[email protected]: \(.*\)@\[email protected]')
   REPO=$(svn info . | sed -ne '[email protected] Root: \(.*\)@\[email protected]')
   BRANCH_URL=$REPO/branch/$branch

   svn copy $URL $BRANCH_URL -m "$msg"
}


# Switch to a branch or tag
function svn_switch()
{
  d=$1; shift
  REPO=$(svn info . | sed -ne '[email protected] Root: \(.*\)@\[email protected]')
  URL=$REPO/$d
  svn switch $URL
}

Ответ 7

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

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

Ответ 8

Нету багажник не лучшее место. В нашей организации мы всегда придерживаемся этого подхода: Trunk содержит код выпуска, поэтому он всегда компилируется. С каждым новым выпуском/вехой мы открываем новую ветку. Всякий раз, когда разработчик владеет элементом, он/она создает новую ветвь для этой ветки релиза и объединяет ее с веткой релиза только после тестирования. Ветвь релиза объединяется в транк после тестирования системы.

Прикрепленное изображение является грубым представлением.

Ответ 9

Еще один пример того, когда старая старая "стабильная магистраль, dev в ветке" становится проблемой:

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

Команда A разрабатывает новую функцию F в /branch/F. Команда B только что запустила еще один филиал, чтобы исправить некоторые проблемы с производительностью, которые возникают на реальном сайте в /branch/P, и первое, что нужно сделать команде B, - это реорганизовать кучу таблиц базы данных и/или как файлы выложены на внешняя файловая система. Это заставляет команду A реорганизовать много новых вещей, прежде чем они смогут продолжить разработку. Затем появляется команда C и делает другую вещь... И вдруг у всех возникла проблема.

Затем наступает фаза слияния - и после этого никто больше не хочет использовать TortoiseSVN.

Ответ 10

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

Мы работаем над ветвями развития, т.е. ветвями /feature 1, и создаем тег qa, копируя ветки /feature 1 → tags/feature1-qa1 и исправляем любые ошибки в ветвях /feature 1 для создания тегов /feature 1-qa1 и т.д. Когда они были готовы к развертыванию, все изменения, которые произошли в ветвях /feature 1 с момента последнего слияния с соединительной линии, объединяются обратно в соединительную линию перед созданием тега окончательной версии i.e. tags/5.1.0.

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