Что происходит для фиксации журналов на ветке после слияния? - PullRequest
40 голосов
/ 26 марта 2010

Сценарий:

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

#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! он слил все свои изменения обратно в багажник! Есть много радости и питья Mountain Dew.

Теперь предположим, что другой программист приходит через неделю и обновляет свою рабочую копию с версии 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

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

Ответы [ 4 ]

43 голосов
/ 11 февраля 2011

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

14 голосов
/ 13 марта 2012

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

9 голосов
/ 26 марта 2010

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


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

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

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

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

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

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

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

2 голосов
/ 04 апреля 2014

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

пример:

svn log -vg

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

...