Рабочий процесс SVN — Курица перед яйцом. Прежде чем объединить 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

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

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

Answer 2

Похоже, вам нужна ветка X на основе магистрали и ветка Y на основе X.

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

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

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

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

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

Answer 3

Я бы хотел, чтобы все новые коммиты отправлялись в багажник, если только нет причины помещать их в другое место.Например, создав разные ветки для 4.1.1 и 4.1.2, в вашем примере лучше всего выполнить слияние ветвей, обе из которых затем могут быть объединены обратно в ствол.Фу!По моему мнению, это ад слияния.

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

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

Answer 4

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

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

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

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

Answer 5

Один из подходов — создать ветку 4.1.2 от 4.1.1, а не от магистрали (и, конечно, 4.1.1 от магистрали).

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