Использование Subversion с рекламной моделью

Question

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

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

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

• Будет ли эта модель работать без проблем при использовании Subversion, несмотря на отсутствие значимого канала?
• Будет ли автоматическое отслеживание слияний работать для обновлений из более ранних веток в более поздние?
• Можно ли закрыть/удалить/игнорировать ветку (в этом примере ветку выпуска «a») без реинтеграции?
• Можно ли создавать ветки функций для каждой ветки выпуска и будет ли для них работать отслеживание слияния?(Они будут следовать рекомендованной модели создания/слияния/реинтеграции.)

Изменить - добавить дополнительную информацию.

Причина, по которой традиционная модель Unstable Trunk может оказаться непригодной, иллюстрируется следующей диаграммой.Функции для каждого выпуска не обязательно реализуются в порядке их выпуска (некоторые клиенты могут не торопиться с подтверждением требований).Мы хотим как можно скорее распространить изменения из более ранних веток на более поздние.

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

В этом случае нам нужна функция 2 (завершенная в ветке a) в ветке b, но поскольку это слияние дочернего и родительского элементов и, следовательно, не поддерживается Subversion, его придется выполнять вручную.Аналогично, функцию 6 придется объединить вручную дважды.Я ожидаю, что это будет относительно медленный и подверженный ошибкам процесс по сравнению с автоматически отслеживаемыми слияниями.

Answer 1

Если я понимаю вашу ситуацию, в ваших требованиях нет ничего, что усложняло бы задачу так, как вы ее представляете.Вы также уделяете слишком много внимания преимуществам автоматического режима по сравнению с автоматическим.объединение вручную (подробнее об этом позже).Ветви CVS были бы другим вопросом, но не с учетом того, как SVN обрабатывает «ветви» (т. е. это не так).

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

Требование о слиянии только вперед звучит так, как будто вам просто нужно объединить ревизии подмножества из основной строки, ревизии после данной ревизии ветки.Выполнение слияний таким образом позволит вам объединять изменения из произвольных ветвей обратно в основную строку так часто, как вам нравится (по мере того, как они подтверждаются вашими клиентами), и их можно будет применять дальше с уверенностью, что применяются только проверенные изменения.Вы можете настроить автоматическое слияние для отслеживания этой версии копии (см. --stop-on-copy и слияния на основе диапазона).Затем ветки выпуска собирают наборы подтвержденных изменений, произошедших с определенного момента.

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

Чтобы ответить на заданные вами вопросы:

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

• Конечно.Это также должно быть достаточно независимо от выбранной вами структуры.В любом случае вам понадобится/хотите отслеживать точки ревизии (возможно, с помощью какого-нибудь простого сценария, в худшем случае).

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

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

Ваше здоровье!

Answer 2

Ты говоришь:

Все работы от более ранних ветвей должны превратить это в более поздние.Работа над более поздними филиалами не должны превращаться в более ранние (это в наших контрактах)

Здесь, если мы заменим ветки релизами (я сомневаюсь, что ваши клиенты знают или интересуются «ветвями»), мы получим:

Все работы из предыдущих релизов должны сделать это в более поздних.Работаем позже релизы не должны делать это в ранее Meme it те (это в наших контрактах)

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