SVN Workflow - Chicken Before the Egg - Перед слиянием V1 с V2 мне нужен код из V1 для работы на V2

Question

Наша распределенная команда (3 внутренних разработчика и более 3 внешних разработчиков) использует SVN для управления нашей кодовой базой для веб-сайта. У нас есть ветка для каждой минорной версии (4.1.0, 4.1.1, 4.1.2 и т. Д.). У нас есть транк, в который мы объединяем каждую версию, когда делаем релиз и публикуем его на нашем сайте.

Пример проблемы, с которой мы сталкиваемся: Добавлена ​​новая функция, назовите ее «Возможность создать проект» в 4.1.1. Еще одна функция, которая зависит от той, что в 4.1.1, должна появиться в 4.1.2, которая называется «Возможность добавлять задачи в проекты».

Итак, в понедельник мы говорим, что 4.1.1 «закрыт» и нуждается в проверке. На этом этапе наши удаленные разработчики обычно начинают работать над функциями / билетами для 4.1.2. В течение недели мы будем тестировать 4.1.1, исправлять ошибки и фиксировать их обратно в 4.1.1. Затем, в пятницу или около того, мы помечаем 4.1.1, объединяем его с транком и, наконец, объединяем его с 4.1.2. Но в течение 4-5 дней, которые мы тестируем, 4.1.2 не имеет кода из 4.1.1, от которого зависят некоторые новые функции для 4.1.2.

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

Что мы можем / должны сделать, чтобы сгладить этот процесс?

P.S. Извиняюсь, если этот вопрос задавался раньше - я выполнил поиск, но не смог найти то, что искал.

Answer 1

Звучит так, как будто вам нужна ветвь X на основе ствола и ветвь Y на основе X.

Вы можете разработать функцию в X и начать ее тестирование. Тем временем вы копируете X в новую ветвь Y и разрабатываете вторую функцию там.

В конце концов X объединяется с транком и освобождается. Затем, когда вы закончите работу над Y, вы можете объединить его с X для тестирования, а затем с транком для выпуска.

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

Если вы делаете это, важно помнить:

• Вы делаете обычные слияния из ствола в X и из X в Y.
• Вы реинтегрируете слияния из X обратно в ствол, а из Y обратно в X.
• После слияния реинтеграции в ствол вам необходимо заблокировать коммит от слияния обратно в X.
• После слияния реинтеграции в X вам необходимо заблокировать коммит обратно в Y.
• Ведите подробные записи о том, какая функция в какой ветке; в противном случае это может быстро запутаться.

Answer 2

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

Вот несколько основных советов из книги Subversion:

http://svnbook.red -bean.com / о / 1,5 / svn.branchmerge.commonpatterns.html

Answer 3

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

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

Answer 4

Один из подходов - это ветка 4.1.2 от 4.1.1 вместо транка (и, конечно, 4.1.1 от транка).

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

Answer 5

Я думаю, есть несколько способов сделать это.

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

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

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