Как управлять несколькими ветками релизов в Subversion?

Question

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

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

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

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

Однако мне интересно, если это правильный путь. Кто-нибудь знает, возможно ли управлять несколькими ветками релизов в Subversion? Конечно, должна быть возможность управлять функциями, которые задерживаются, не ставя под угрозу способность выполнять слияния.

Есть ли у кого-нибудь опыт в отношении сценария, который я представил, которым вы бы хотели поделиться? Я просто хотел бы знать, как я могу улучшить способ управления выпусками на моем рабочем месте, чтобы это больше не повторилось.

Answer 1

Если честно, я не совсем уверен, как ваша система работает из описания. Однако в прошлом мне приходилось управлять проектами с несколькими живыми версиями. То, как мы это сделали, было:

1. Ничего не освобождается, чего нет в багажнике
2. Каждая версия получает собственную ветку версии.
3. Единственный способ обновить ветку версии - это объединение из транка.

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

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

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

Также см. Мой ответ здесь .

Answer 2

Это не то, где черепаха превосходит. Для выполнения сложных сценариев слияния и ветвления вам нужно что-то вроде спецификации конфигурации clearcase для управления версиями.

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

Answer 3

У моей компании были похожие проблемы.

У нас была задержка проекта на один релиз - назовем его 2.0 - на несколько месяцев. Тем временем у нас были производственные проблемы в текущей ветке - назовем это 1.5 - что требовало большего количества выпусков. Мы не могли использовать транк, потому что у него были эмбарго, поэтому мы начали ветвиться с веток. Наш релиз 1.6 разветвленный от 1.5, а не багажник. Помимо соглашения об именах, релиз 1.6 на самом деле не более, чем 1.5.1. Поскольку это не SOP, мы очень тщательно документировали, что делаем.

И я не с нетерпением жду точки слияния, где мы наконец соберем ветку 1.6 и 2.0. Мы не можем объединить изменения на 1.6 обратно в транк или 2.0, потому что это только ухудшает QA на проблемах 2.0. Мы работаем с Subversion 1.4.6, так что никакой помощи со стороны программного обеспечения нет - это будет все слияние вручную.

Answer 4

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

В этом случае ветвление Spepladder (?) Будет работать хорошо - просто оставьте багажник и поднимитесь наверх.

Answer 5

Я думаю, что вы хотите отслеживать слияние, либо через svnmerge.py, либо через встроенное отслеживание слияний из Subversion 1.5. Это позволяет блокировать определенные изменения от объединения в ветвь, что затем можно сделать для всех изменений, связанных с функциями, которые вы хотите включить только в следующий выпуск.