Использование SVN с разработкой нескольких релизов

Question

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

Я прочитал большую часть книги SVN и провел много исследований о том, как другие используют SVN.

Я собираюсь дать краткий обзор того, как мы используем SVN, и, надеюсь, у кого-то есть какие-то предложения для меня.

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

Обычно у нас есть две, иногда три запланированные доставки, выполняемые одновременно.Например, я мог бы писать код для выпуска 3, но я или другие тестируем для выпуска 2 и вносим окончательные исправления ошибок для выпуска 1. В то же время может также происходить производственное исправление.

Прямо сейчасмы делаем много слияний, чтобы синхронизировать ветки (каждый выпуск).Выпуск 3 нуждается в коде из 2 и 1, но мы, очевидно, не хотим, чтобы новый код из выпуска 3 попал в выпуск 1. Таким образом, мы бы сделали серию слияний от выпуска 1 к выпуску 2 и от выпуска 2 к выпуску 3. Этобудет повторяться на регулярной основе, чтобы кодировщики в выпуске 3 имели исправления ошибок от 2 или 1.

Всякий раз, когда выпускается или производственное исправление запускается в производство, мы объединяем код обратно в транк.Затем мы объединяем его из ствола (или ветки релиза, которая только что была запущена в производство) во все активные ветки.

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

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

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

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

Есть ли у кого-нибудь идеи о том, как мы можемлучше использовать возможности SVN, чтобы мы могли избавить себя от этой головной боли и убедиться, что все всегда работают с теми версиями кода, которыми они должны быть!

Спасибо!

Answer 1

Я не знаю, что вы можете реально решить такую ​​ситуацию с помощью вопросов и ответов на форуме.Лучшим вариантом может быть поиск профессиональных услуг от компании, такой как мой работодатель, CollabNet. Опции обучения Subversion

Давайте на мгновение отложим имена, такие как «ствол», так как эти вещи означают то, что вы хотите, чтобы они имели в виду.Я являюсь одним из коммиттеров Apache Subversion, и я бы порекомендовал заняться разработкой так же, как мы это делаем для самого Subversion.

1. Практически вся разработка выполняется в одном месте, которое мы называем trunk, но его можно назвать"development" или "unstable" или любое другое имя, которое вы хотите.
2. Некоторая работа над новыми функциями будет выполняться в ветвях функций, созданных из ствола.Они, как правило, недолговечны и по усмотрению разработчика.Мы стараемся постоянно поддерживать нашу магистраль (все тесты проходят), поэтому иногда люди хотят сначала попробовать деструктивные изменения в ветке.
3. В какой-то момент мы думаем, что транк получил те функции, которые нам нужныотметьте, что пришло время сделать релиз, поэтому ветка релиза создается путем копирования ствола.
4. Мы не разрешаем никакой разработке в ветке релиза.Ошибки исправляются в транке, а ревизии, содержащие исправление, назначаются для возврата в один или несколько выпусков.Если утверждено, то ревизия (и) объединяются с веткой (версиями) выпуска, для которой они были утверждены.
5. Иногда магистральная линия достаточно сильно отклоняется от выпуска, чтобы исправление не сливалось корректно.Когда это происходит, мы создаем ветку backport, копируя ветку релиза и затем объединяя исправление из ствола с веткой backport.Это дает разработчику возможность надлежащим образом разрешать конфликты слияния в ветке, а другие разработчики должны надлежащим образом проверить и проголосовать за то, должна ли ошибка быть перенесена обратно.

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

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