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

Question

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

В: Существует ли способ "одним щелчком мыши" получить все номера ревизий, которые не были объединены из ветви X в транк?

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

Кажется, что команда svn mergeinfo здесь не помогает. Передача корневых веток и ветвей завершится неудачей, если слияние было выполнено не на корневом уровне (и это распространенный сценарий).

Сценарии, инструменты, любые svn-хуки в качестве решения приветствуются.

приписка

Последняя версия SVN. Не нужно спорить, насколько распространен или хорош этот сценарий;)

Answer 1

Вы можете сделать это очень легко, если вы используете относительно новую версию 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 / ru / 1.5 / svn.ref.svn.c.mergeinfo.html

Answer 2

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

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

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

Answer 3

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

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

Удачи.

Answer 4

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

svn log --verbose

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

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

Answer 5

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

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

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 для вашего почтового уведомления.

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

Answer 6

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

о

Answer 7

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

Что я нашел в $ svn help merge, так это совет не делать слияния поддеревьев:

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

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

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

Answer 8

Основано на ответе 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 |'

Answer 9

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

Answer 10

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