Подверсия: находка с практическими рекомендациями все изменения, которые не объединяются с соединительной линией?
Переходящие источники для цикла выпуска являются одним из сценариев управления общим источником. Слияние как можно скорее является хорошей практикой. Таким образом у нас есть человеческий фактор: ответвление закрывается, но кто-то забыл объединять что-то назад для транкинга.
Q: Существует ли "один щелчок" способ получить все числа пересмотра, которые не были объединены от ответвления X для транкинга?
(Примечание: Мне не нужны эти числа пересмотра для нахождения, что объединиться, мне нужны они для создания автоматизированной проверки, которая напомнила бы людям удостоверяться, что они не забыли объединять что-то для транкинга. Слияние себя не является проблемой.)
На svn mergeinfo сбои команды походит помогать здесь. Передача ответвления и магистральных корней перестанет работать, если слияние было выполнено не на корневом уровне (и это - общий сценарий).
Сценарии, инструменты любой вид рычагов svn как решение приветствуются.
P.S.
Последняя версия SVN. Никакая потребность обсудить, насколько распространенный или хороший этот сценарий ;)
8 ответов
Короткий ответ: Я так не думаю.
Длинный ответ: В итоге я написал питоновый сценарий, чтобы ответить на этот вопрос. Всякий раз, когда разработчики объединяют changeset, они должны ставить "merged rXXX" в сообщение журнала. (Это было до того, как svn:mergeinfo существовал) Скрипт анализирует все живые svn ветки + ствол и рекурсивно сканирует все "слитые" ссылки, выводя список изменений для каждого разработчика, которые они не сливали.
[обновление] Ответ из @tmont лучше теперь, когда у каждого есть версия svn, которая поддерживает svn mergeinfo - show-revs eligible и svn merge --record-only только для тех случаев, когда вы хотите записать только логическое исправление.
По этой причине CVS создал тег для обозначения корня ветки :) Для SVN это должно выглядеть так:
+ trunk / project1
+ tags / project1-b1-root
+ branches / project1-b1
Примечания:
- Тег project1-b1-root и ветка project1-b1 создаются одновременно из магистрали .
- Никто не должен фиксировать project1-b1-root (вы можете ограничить эту операцию для тегов / путь).
- Когда все утверждали, что он все поместил в ствол, вы делаете различие между project1-b1-root и project1-b1 и пытаетесь применить его к стволу: изменения, которые уже были применены, будут автоматически пропущены, в остальном вы увидите разницу или коллизии.
Я бы не стал беспокоиться о конкретных номерах изменений, которые необходимо произвести слияние, а просто посмотрел на различия:
Сначала обновите боковое ответвление со стволом (или посмотрите, что будет слито):
cd branch-dir
svn merge --reintegrate http://svnrepo/path-to-trunk .
svn ci -m'making this branch current'
cd ../trunk-dir
svn merge --dry-run http://svnrepo/path-to-trunk http://svnrepo/path-to-branch .
svn ci -m'merging in all unmerged changes from <branch>'
Запомните, команды svn слияния выглядят точно так же, как команды svn diff - вы создаёте diff/patch, а затем примените его к определённому месту. Эта команда слияния, приведённая выше, просто говорит: "возьмите все различия между стволом и ответвлением и примените их к рабочей копии ствола". Таким образом, вы можете так же легко изменить эту вторую команду слияния на diff для вашего почтового уведомления.
Не забудьте проверить различия перед фиксацией в каждом случае, чтобы убедиться, что ничего плохого не произошло. Вам также может понадобиться разрешить некоторые конфликты.
Я понимаю, что в вашем случае, возможно, уже слишком поздно для этого, но что я делаю для такого рода вещей, так это устанавливаю конвенцию для коммитов слияния, чтобы их можно было идентифицировать позже. Например, "Слияние [1234]: ...(полный лог коммитов 1234)...". Тогда я смогу разобрать его из svn logа с помощью скрипта позже.
Чтобы убедиться, что вся ваша команда сделает это, сделайте объединение в скрипт и поместите его в свой проект. (например, ./scripts/merge 1234). Люди, как правило, даже оценят это, вдвойне, так что если скрипт сделает слияния проще, чем команда raw svn будет делать такие вещи, как автоматическое выяснение исходного url
Удачи.
Из-за отсутствия серебряной пули, дисциплинированным способом является сохранение записей о том, что было слито и откуда.
Будет ли svn merge --dry-run предоставить вам необходимые сведения?
Извините, что у меня дома нет SVN-сервера, чтобы проверить это прямо сейчас, но можно ли команду:
svn log --verbose
Которую вы можете разобрать? Я не уверен, что вывод после объединения обратно в main, но вы, возможно, сможете разобрать (используя скрипт, которого у меня нет, так как только я использую свой SVN сервер) лог и прочитать все файлы, которые были проверены, а затем искать ключевое слово, указывающее на то, что файл был объединен в main?
Я постараюсь проверить его как-нибудь вечером, когда вернусь домой, если у меня будет немного времени.
Вы можете сделать это очень легко, если используете относительно новую версию Subversion (я думаю, 1.5 или выше) с подкомандой mergeinfo .
svn mergeinfo --show-revs eligible svn://repo/branches/your-branch-name svn://repo/trunk
Это покажет вам все ревизии, которые могут быть объединены в ствол из ветки "your-branch-name".
Источник: http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html