Что происходит, чтобы зафиксировать журналы на ветке после слияния?

Сценарий:

Программист создает ветку для проекта 'foo' под названием 'my_foo' в версии 5
Программист делает несколько изменений в нескольких файлах, когда работает над функцией "my_foo".
В конце каждого основного шага, скажем, добавляя несколько новых функций в класс, программист делает svn commit в соответствующих файлах, поэтому передавая их ветке
Спустя несколько недель и позже многие коммиты (каждая фиксация имеет журнал фиксации, описывающий, что он сделал), программист объединяет ветку обратно в туловище:


#Assume the following is being done from inside a working copy of the trunk:
svn merge -r 5:15 file:///path/to/repo/branches/my_foo

Hazzah! он объединил все свои изменения обратно в багажник! Там много радости и питья горной росы.

Теперь позвольте сказать, что еще один программист приходит через неделю и обновляет свою рабочую копию от версии 5 до версии 15. "Ух ты", говорят они. "Интересно, что изменилось с момента пересмотра 5". Затем программист делает svn status на своей рабочей копии и получает что-то вроде этого:

------------------------------------------------------------------------
r15 | programmer1 | 2010-03-20 21:27:04 -0400 (Sat, 20 Mar 2010) | 1 line

Merging Version 2.0 Changes into trunk
------------------------------------------------------------------------
r5 | programmer2 | 2010-02-15 10:59:55 -0500 (Mon, 15 Feb 2010) | 1 line

Added assets/images/tumblr_icon.png to trunk

Что, черт возьми, случилось со всеми примечаниями, которые другой программист применил ко всем своим обязательствам в своей ветке? Неужели те, кого не срывают во время слияния? Я с ума сошел или просто что-то забыл?

Ответ 1

Ответ устарел, теперь у нас есть svn log -g.

Нет, ты не сумасшедший. Вот как это работает, к сожалению.

Лучшее, что вы можете сделать, это включить в сообщение фиксации для слияния URL-адреса ветки и номера версии, чтобы можно было вручную просмотреть журнал изменений для этой ветки. (Данные все еще есть, конечно).

Однако вы не знаете, какие из изменений внесли его в багажник, а какие нет.

Если на соединительной линии не было или мало изменений, возможно, потребуется выполнить обратное слияние (слияние с соединительной линии на ветку), а затем заменить соединительную линию веткой. Подобные рассуждения также могут быть сделаны для отдельных подпапок (например: замените подпапку реализации синтаксического анализа XML из ветки, сохраните остальные). Замена папок (с помощью svn delete, svn copy) сохранит историю изменений.

Для файлов, которые были добавлены во время слияния, их история изменений может быть скопирована из ветки, если вы использовали команду svn copy. Не уверен, что команда merge включает поддержку этого.

Может быть интересно узнать, есть ли инструмент для svn, который выполняет "rebase" (как в git или mercurial). Это создало бы отдельные фиксации для каждого изменения на ветке. С другой стороны, возможно, отдельные коммиты слишком много беспорядка.

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

Ответ 2

Попробуйте svn log -g включить историю слияния, которая хранится с Subversion 1.5.

Ответ 3

В TortoiseSVN установлен флажок "Включить объединенные ревизии" внизу диалогового окна "Показать журнал", чтобы включить комментарии, переданные ветвям.

Ответ 4

Хорошие ответы... Если вы также хотите знать проверенные файлы и, возможно, имя ветки, установите опцию -v [--verbose] с -g [--use-merge-history].

Пример:

svn log -vg

Выход будет иметь полный путь к проверенным файлам (даже объединенной ветке), а также сообщение (из 'revision_url') для добавления файлов в ревизию с помощью слияния.