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

вы можете сделать это очень легко, если вы используете относительно новую версию Subversion (1.5 или выше, я думаю) с mergeinfo суб-команды.

svn mergeinfo --show-revs eligible svn://repo/branches/your-branch-name svn://repo/trunk

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

Источник:http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html

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

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

удачи.

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

во-первых, приведите боковую ветвь в соответствие с trunk (или посмотрите, что будет объединено):

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

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

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

svn log --verbose

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

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

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

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

Примечания:

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

будет svn merge --dry-run дать вам детали, которые вам нужны?

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

на основе эфирответ выше, из ветки, которую вы хотите проверить на несвязанные ревизии

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 |'

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

что находится в $ svn help merge Это совет не делать под дерево сливается:

Если вы хотите объединить только поддерево, то путь к поддереву должен быть включено в оба источника и TARGET_WCPATH; это уныние, чтобы избегайте поддерева mergeinfo

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

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

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

o