Проблема слияния подклипа - Пробный прогон не соответствует результатам слияния - PullRequest
0 голосов
/ 22 февраля 2012

Я использую плагин Subclipse 1.6x в Eclipse. Позвольте мне сначала объяснить сценарий:

Скажем, у меня есть ствол моего проекта с ревизиями от r1 до r100. В ревизии r100 я создал ветку и начал фиксировать, скажем, от r101 до r105. На данный момент, я думал, что внесу любые изменения из ствола, чтобы обновить мою ветку.

Но из-за ошибки слияния я в итоге слил r80 из транка в свою ветку и зафиксировал его как ревизию r106. Поэтому я возвращаю свое изменение в r106 в ветке и выполняю другой коммит r107 в этой ветке.

За это время были зафиксированы коммиты, скажем, r108 и r 109 в багажнике. Теперь, после возврата моего плохого коммита в r106, я корректно перенесу все изменения от транка до r109 в свою ветку (путем слияния), чтобы моя ветка была обновлена, и фиксирует это в моей ветке как r110.

Все хорошо. Теперь я решил, что мне не нужна ветка, поэтому позвольте мне объединить все изменения в ветке (r110) обратно в транк. Поэтому после этого слияния все, что я должен увидеть, - это изменения, которые я сделал в ветви (ревизии r 101 и позже в этой ветви), так как моя ветвь обновлена ​​с магистралью.

Я делаю Команду -> Слияние с URL-адресом в качестве транка и URL-адресом в качестве пути моей ветки. Редакция От - это последняя объединенная ревизия в соединительной линии (r109), а ревизия До - самая последняя в моей ветви (r110). Я попробовал пробный запуск, а также создал параметр Unified Diff file в окне Merge. Они оба выглядят правильно, и единственные обновленные файлы - это те, которые я изменил в своей ветке.

Теперь я запускаю Merge, и результат объединения отличается от Dry Run. Сначала он корректно объединяет файлы, показанные Dry Run (что я и ожидал). Но это не останавливается там. Затем он пытается что-то вроде этого: --- слияние с r80 по r110 (может быть из-за моего неправильного слияния в ветке ???)

и затем делает что-то вроде: --- обратное слияние от r110 до r80.

Конечным результатом было слияние всех моих изменений точно так же, как и результат пробного запуска, плюс множество обновлений / изменений в других файлах (я полагаю, из-за второго слияния и обратного слияния).

Любые мысли о том, почему это может происходить и как сделать результат слияния корректным / таким же, как результат пробного прогона? Даже созданный файл Unified diff является правильным.

Спасибо, что прочитали длинный пост.

Ответы [ 2 ]

1 голос
/ 22 февраля 2012

Диалоговое окно слияния Subclipse не работало со времен Subversion 1.5 и введения отслеживания слияний. Я бы посоветовал вам установить плагин CollabNet Merge Client, который включен в сайт обновлений Subclipse, и посмотреть, получите ли вы те же результаты.

Опция Team> Merge должна вызвать мастера, если этот клиент установлен.

0 голосов
/ 29 февраля 2012

Хорошо, я понял это или, по крайней мере, решил для моего случая.Проблема была в том, что на моей ветке я ошибочно слил r80 из багажника и зафиксировал как r106.Затем я сделал Team> Revert> last commit, чтобы отменить этот коммит-коммит и проверил это как новый коммит r107.

Есть 2 проблемы с этим.Во-первых, это не лучший способ отменить коммит слияния в SVN.Google для более подробной информации.

Вторая проблема - когда вы объединяете эти изменения (в нескольких коммитах) обратно в транк, SVN попытается применить каждый коммит один за другим к транку.Когда я перепутал r106 на ветке, объединив r80, SVN запутался в изменении из-за конфликтного происхождения файлов.Чтобы избежать этого и сказать SVN, не беспокойтесь о происхождении, а просто объедините различия / изменения в моей ветке с транком, отметьте опцию «Игнорировать происхождение» в окне «Слияние».Это позаботилось о проблеме для меня.

Также в качестве примечания, при слиянии SVN результат Dry Run эквивалентен выполнению Diff между файлами.Но когда вы выполняете слияние, он просматривает происхождение файла и вводит каждый коммит один за другим, чтобы выполнить слияние.Следовательно, результаты не всегда могут быть одинаковыми.Подробнее об этом в документации SVN.

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

...