Как убедиться, что исправления ошибок в ветке версий в Subversion объединены в транк

Question

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

Есть ли способ контролировать слияния, чтобы убедиться, что они выполнены?

Или есть лучший способ использовать ветвление Subversion для получения лучших результатов.

ОБНОВЛЕНИЕ: Люди указали, что решение должно включать систему отслеживания ошибок. Мы используем Jira и помечаем каждый коммит идентификатором проблемы Jira. Никакой дальнейшей интеграции не осуществляется прямо сейчас.

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

Answer 1

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

Чтобы убедиться, что закрытая ошибка действительно устранена, специалисты по QA / тестированию должны проверить, что ошибка * * исправлена ​​ во всех поддерживаемых выпусках.

Отслеживание слияний SVN может помочь некоторым, но, в конечном счете, оно не может сказать вам:

• была ли ошибка исправлена ​​несвязанным изменением транка, и этот патч не был нужен?
• патч из ветки не работал на транке из-за других изменений?
• патч из ветки вообще не применялся к транку, а для транка требовался другой патч?

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

Answer 2

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

Answer 3

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

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

Answer 4

Нет ничего в SVN, чтобы сказать вам, какой код вы должны или не должны проверять, ветвиться, объединять или удалять. Это не его работа. Он отлично справляется со своей задачей - предоставляет вам инструмент для управления версиями для хранения вашего кода.

Итак, вам не нужен инструмент для лучшего управления вашим кодом, вам нужна внешняя система для лучшего управления разработчиками:)

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

SVN может интегрироваться с этими инструментами, например, мой репозиторий обновляет мой багтрекер Mantis при добавлении некоторых волшебных слов в проверку (если вы введете «исправленный богомол # 1234» в комментарии проверки, ошибка богомола 1234 будет обновлена ​​с помощью измененные файлы и их статус изменен на «ожидание теста»)

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

Итак, проблема здесь не в SVN, а в ваших процессах разработки.

Answer 5

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

Вы можете найти скрипт по адресу: http://github.com/ccampbell/show-missing-revs

Допустим, у вас есть ветка релиза 2.0. Чтобы узнать все, что зафиксировано в 2.0, еще не было объединено с транком:

cd /path/to/trunk
sh /path/to/show_missing_revs.sh -b 2.0 -u username (optional) -v (verbose)

Это выведет что-то вроде:

r2532 | username | fixing bug with this
r2631 | username | fixing bug with that

Это требует Subversion 1.5, я верю. Надеюсь, вы найдете это полезным!

Answer 6

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

Answer 7

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

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

Answer 8

Более новые версии Subversion (я думаю, начиная с 1.5 или 1.6) имеют отслеживание слияния. Таким образом, Subversion отслеживает, какие из изменений в ветви были объединены с транком.

Вы можете объединить все изменения из ветви в ствол, используя команду:

svn co https://server/repo/trunk
cd trunk
svn merge --reintegrate https://server/repo/branches/branch_name
<check merge results, run unit tests, etc>
svn commit

Подробнее см. Руководство по Subversion .

Таким образом, вы получите все изменения, сделанные в ветке, чтобы добраться до транка. Однако, если вы не хотите получать все изменения от ветви к стволу, вы должны использовать svn diff, чтобы заметить изменения и выбрать изменения, которые вы хотите объединить.