Subversion ответвление

Question

Я хочу представить следующую модель ветвления в моем проекте

версия1 -> версия2 -> версия3 -> версия4 -> и т. Д.

так 1) Нет магистрали 2) Каждыйверсия отличается от предыдущей

Не будет ли здесь проблема производительности, связанная с постоянно увеличивающейся "глубиной ветки"?

Заранее спасибо

Answer 1

базовый подход превосходит модель продвижения

Я бы рассмотрел "Модель продвижения", в которой одна версия напрямую основана на ее предшественнике, как анти-шаблон,Однако это не создаст серьезных проблем с производительностью.Пока у вас нет четкого параллельного развития, вы можете хорошо с ним жить.Как и со «стандартной» базовой моделью.В прошлом это работало для меня на довольно линейном проекте.

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

Потенциально больше слияний, которые также сложнее отслеживать.Дисциплина для проверки исправлений ошибок only до последней версии имеет решающее значение в вашем сценарии.

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

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

в двух словах:

trunk
branches
  1
  2
  3
tags
  1.0
  1.1
  1.2
  2.0
  2.1

• развиваться нестабильновещи в стволе
• разветвляются из ствола в ветку обслуживания / выпуска (например, "2")
• стабилизируют и проверяют это
• создают тег 2.0
• освободить помеченный код
• зафиксировать исправления ошибок в "2"
• проверить снова
• создать тег 2.1
• выпустить помеченный код
• объединить ВСЕ изменения из "2" в транк
• объединить в "1", если версия 1 все еще поддерживается
• тег 1 как 1.2
• выпуск из тега

Я рекомендую это (старое), но очень правильное чтение: http://www.vance.com/steve/perforce/Branching_Strategies.html

Answer 2

Нет. Мы регулярно делаем что-то очень похожее на это. Когда мы внедряем версию в производство, мы создаем ветку, чтобы сохранить состояние в точности так, как оно пошло в производство. Тогда багажник станет нашим очередным регулярным выпуском. Но если, как это часто случается, возникает ошибка или какое-либо другое исправление, мы создаем новую ветку из производственной ветки. Когда приходит следующее исправление, мы создаем ветку от предыдущей ветви исправления. И т. Д. Так вроде, скажем, у нас есть ветки / Release-10. Затем у нас есть исправление, поэтому мы копируем Release-10 в Release-10-1. Если у нас есть еще одно исправление, мы копируем Release-10-1 в Release-10-2. И т.д. Я не видел особых проблем с этой схемой. (Мы должны объединить исправления обратно в магистраль, но я подумаю, что с любой схемой вам придется это делать.)

Когда вы копируете ветку, SVN на самом деле не копирует все. Он просто копирует указатели. Одним из хвастовств SVN является то, что стоимость создания филиала очень мала.