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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Редактировать: Я бы также рекомендовал прочитать SCM Patterns .

Answer 4

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

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

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

Как Ганнибал всегда говорил в «Команде А»: «Мне нравится, когда план объединяется».

Answer 5

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

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

Answer 6

Я создал пару shell-скриптов для упрощения создания кратковременных веток разработки:

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

   URL=$(svn info . | sed -ne 's@URL: \(.*\)@\1@p')
   REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
   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 's@Repository Root: \(.*\)@\1@p')
  URL=$REPO/$d
  svn switch $URL
}

Answer 7

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

Мы работаем над ветвями разработки, то есть ветками / feature1, и создаем тег qa, копируя ветки / feature1 -> tags / feature1-qa1 и исправляем любые ошибки в ветках / feature1 для создания тегов / feature1-qa1 и т. Когда все было готово к развертыванию, все изменения, которые произошли в ветвях / feature1 с момента последнего слияния с транком, объединяются с туловищем перед созданием тега окончательного выпуска, т. Е. Tags / 5.1.0.

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

Answer 8

Еще один пример того, как старый добрый процесс "stable trunk, dev in branch" становится проблемой:

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

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

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

Answer 9

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

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

Answer 10

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

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