Что, оказывается, фиксирует вход в систему ответвление после слияния?
Сценарий:
- Программист создает ответвление для 'нечто' проекта, названного '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! он объединил все свои изменения назад в соединительную линию! Существует много радости и питья 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
Какого черта произошел со всеми примечаниями, которые другой программист вставил со всеми его фиксациями в его ответвлении? Разве они не добираются, остановился во время слияния? Я являюсь сумасшедшим или просто забываю что-то?
1 ответ
Ответ устарел , теперь, когда у нас есть svn log -g .
Нет, ты не сумасшедший. К сожалению, так это работает.
Лучшее, что вы могли сделать, - это включить в сообщение фиксации для слияния URL-адрес ветки и номер версии, чтобы можно было вручную искать журнал ревизий для этой ветки. (Данные все еще там, конечно).
Однако вы не знаете, какие из изменений внесли его в ствол, а какие нет.
Если в стволе изменений не было или было мало изменений, можно было бы выполнить обратное слияние (слияние из ствола в ветвь), а затем заменить ствол ветвью. Этот тип рассуждения также могут быть выполнены для отдельных подпапок (например: заменить подпапку реализации синтаксического анализатора XML из ветки, оставить остальные). Замена папок (с помощью svn delete, svn copy) сохранит историю изменений.
Для файлов, которые были недавно добавлены во время слияния, их историю изменений можно скопировать из ветки, если вы использовали команду svn copy. Не уверен, что команда слияния поддерживает это.
Было бы интересно узнать, есть ли инструмент для svn, который выполняет «перебазирование» (например, git или mercurial). Это создаст индивидуальные коммиты для каждого изменения в ветке. С другой стороны, возможно, отдельные коммиты - это слишком много беспорядка.
Лучшая рекомендация, которую я могу дать, - это использовать хороший пользовательский интерфейс, такой как Trac, который упрощает просмотр истории изменений, чтобы вы могли посмотреть, что произошло в ветке.