Subversion: как найти все изменения, которые не объединены с trunk?

Ответ 1

Короткий ответ: Я так не думаю.

Длинный ответ: в итоге я написал python script, чтобы ответить на этот вопрос. Всякий раз, когда разработчики объединяют набор изменений, они должны помещать "объединенный rXXX" в сообщение журнала. (Это было до того, как существовал svn: mergeinfo) script анализирует все ветки svn в реальном времени + соединительную линию и рекурсивно сканирует все "объединенные" ссылки, выводя список изменений, которые они не объединили для каждого разработчика.

[обновление] Теперь ответ от @tmont лучше, когда у каждого есть версия svn, которая поддерживает svn mergeinfo --show-revs eligible и svn merge --record-only для тех случаев, когда вы хотите только записать логическое исправление.

Ответ 2

Вы можете сделать это очень легко, если вы используете относительно новую версию 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

Ответ 3

Я понимаю, что ваше дело, вероятно, слишком поздно для этого, но то, что я делаю для такого рода вещей, заключается в том, чтобы установить соглашение об объединении, чтобы они были идентифицированы позже. Например, "Слияние [1234]:... (полный журнал фиксации 1234)...". Затем я могу проанализировать его из svn log с script позже.

Чтобы убедиться, что вся ваша команда делает это, сделайте соглашение о слиянии в script и поместите его в свой проект. (например,./scripts/merge 1234). Люди, как правило, даже оценивают это, вдвойне, поэтому, если script упрощает слияние, чем команда raw svn, будет делать так, как автоматически вычислять исходный url

Удачи.

Ответ 4

Я бы не стал беспокоиться о конкретных номерах изменений, которые нужно объединить, а просто посмотрите на diffs:

Сначала верните боковую ветку с помощью соединительной линии (или посмотрите, что будет объединено):

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 merge выглядят так же, как команды svn diff - вы создаете diff/patch, а затем применяете это к определенному местоположению. Эта команда слияния, приведенная выше, просто говорит: "Возьмите все различия между туловищем и веткой и примените их к рабочей копии ствола". Таким образом, вы можете так же легко изменить эту вторую команду слияния в diff для вашего почтового уведомления.

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

Ответ 5

Мне жаль, что у меня нет моего SVN-сервера дома, чтобы проверить это прямо сейчас, но может ли команда:

svn log --verbose

Что вы могли бы разобрать? Я не уверен в выходе после того, как вы снова объединились, но вы можете проанализировать его (используя script, который у меня нет, поскольку я единственный, использующий мой SVN-сервер), журнал и прочитайте все файлы, которые были проверены, а затем найдите ключевое слово, указывающее, что файл был объединен с основным?

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

Ответ 6

По этой причине CVS создал тег, чтобы отметить корень ветки:) Для SVN, который должен выглядеть так:

+ trunk / project1
+ tags / project1-b1-root
+ branches / project1-b1

Примечания:

• Тег project1-b1-root и ветвь project1-b1 создаются одновременно с соединительной линии.
• Никто не должен связываться с project1-b1-root (вы можете ограничить эту операцию для тегов/путей).
• Когда все утверждали, что он поместил все в багажник, вы делаете разницу между project1-b1-root и project1-b1 и пытаетесь применить его к туловищу: изменения, которые уже применяются, будут пропущены молча, для остальных вы увидите разницу или столкновения.

Ответ 7

Будет ли svn merge --dry-run предоставить вам необходимую информацию?

Ответ 8

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

Ответ 9

На основе Ether ответьте выше, из ветки, который вы хотите проверить на невостребованные версии

svn merge --dry-run http://svnrepo/path-to-merge-source .  \
| grep Merging                                             \
| sed 's/--- Merging//'                                    \
| sed 's/into.*//'                                         \
| sort -u                                                  \
| sed 's/ through r/:/'                                    \
| sed -e :a -e N -e 's/\n//' -e ta                         \
| sed 's/ r/ -r/g'                                         \
| sed 's|^|svn log http://svnrepo/path-to-merge-source |'

Ответ 10

Я наслаждаюсь вашей нитью после 3 лет ее создания. И я считаю, что решение по вашей задаче по-прежнему не существует в том виде, в котором вы его выразили:)

То, что я нашел, хотя в $ svn help merge - это рекомендация не выполнять слияния поддерева:

Если вы хотите объединить только поддерево, то путь поддерева должен быть включены как в ИСТОЧНИК, так и в TARGET_WCPATH; это обескуражен, чтобы избегать поддерева mergeinfo

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

Было бы обязательным установить некоторый элемент управления для операции слияния, поскольку в противном случае любой, имеющий доступ на чтение к одной ветки, и запись доступа к другому, может выполнить слияние от первого до второго. Итак, актуальный вопрос: как управлять слиянием поддерева))

Ответ 11

Я написал веб-приложение Java с использованием Wicket и SVNKit для поиска не объединенных ревизий между ветвями, он может быть настроен на то, что вы хотите... ссылка

о