Каков правильный способ сделать слияние Subversion в Eclipse?

объединение всей ветви в ствол

1. проверьте историю проекта филиала, чтобы определить версию, из которой был взят филиал

   • по умолчанию Eclipse Team "история" показывает только последние 25 ревизий, поэтому вам придется нажать кнопку в этом представлении с надписью "показать все"
   • когда вы говорите "показать все", это вернет вас назад мимо даты ветки и покажет вам всю историю для ствола, так что вы будете иметь для поиска вашего комментария, где вы ветвистыми
   • Примечание: если вы используете Tortise SVN для этой же задачи (перейдите к ветке и выберите "Показать журнал"), он покажет вам только историю ветки, чтобы вы могли точно сказать, где началась ветка

2. Итак, теперь я знаю, что 82517 был первым идентификатором версии истории филиала. Таким образом, все версии ветви 82517 имеют изменения, которые я хочу объединить в хобот

3. Теперь перейдите в проект "магистраль" в рабочей области Eclipse и выберите "щелкните правой кнопкой мыши-Team-Merge"

4. представление по умолчанию-1 url merge

   • выберите URL-адрес филиала, из которого вы сливаете
   • в разделе редакции выберите "Все"
   • нажмите OK

5. Это приведет вас к перспективе "синхронизация команды" (если это не так, вы должны пойти туда самостоятельно) для разрешения конфликтов (см. ниже)

повторное слияние дополнительных изменений ветвей в магистраль

1. Insepct история проекта магистрали, чтобы определить последний раз, когда вы слились в магистраль (вы должны были прокомментировать это)

   • для аргументации предположим, что эта версия была 82517

2. Итак, теперь я знаю, что любая версия больше 82517 в ветке должна слиться в ствол

3. Теперь перейдите в проект "магистраль" в рабочей области Eclipse и выберите "щелкните правой кнопкой мыши-Team-Merge"

4. представление по умолчанию-1 url merge

   • выберите URL-адрес филиала, из которого вы сливаете
   • в разделе редакции выберите переключатель " редакции "и нажмите кнопку"Обзор"
   • это откроет список последних 25 ревизий филиала
   • выбрать все ревизии с числом больше 82517
   • нажмите OK (вы должны увидеть список изменений в поле ввода рядом с переключателем)
   • нажмите OK

5. Это приведет вас к перспективе" синхронизация команды " (если это не так, вы должны пойти туда сами), чтобы решить конфликты (см. ниже)

Разрешения Конфликтов

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

2. для каждого файла, где вы видите конфликт выберите "щелкните правой кнопкой мыши-редактировать конфликты"(Не дважды щелкните файл, он вызовет инструмент commit diff version, это совсем другое)

   • если вы видите такие вещи, как ">>>>>> .слияние-правильно.r84513 " тогда вы находитесь в неправильном режиме редактирования

3. Как только вы разрешите все конфликты в этом файле, скажите файлу "пометить как объединенный"

4. Как только все файлы будут свободны от конфликтов, вы можете синхронизировать свой проект Eclipse и зафиксировать файлы в SVN

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

используйте интеграцию Eclipse, она отлично работает.

основное изменение от CVS заключается в том, что вы объединяете только дельты из ветви, т. е. изменения из одной ревизии в другую. То есть вы должны как-то отслеживать правильную начальную ревизию (если у вас нет истории слияния svn 1.5)

Если вы получили это право, это только до вас, чтобы сделать изменения прямо с сравнить редактора.

во-первых, если вы видите ">>>>>" и такие в ваших файлах, когда вы просматриваете их в Eclipse, это, вероятно, означает, что вы не смотрите на файл с соответствующим редактором сравнения. Попробуйте щелкнуть правой кнопкой мыши файл в представлении проекта или синхронизировать представление и выбрать "редактировать конфликты", чтобы вызвать редактор сравнения, который покажет вам конфликтующие регионы графически, а не как текст. Обратите внимание, что редактор сравнения, который подходит для "редактировать конфликты" отличается от того, который вы получаете когда вы просто дважды щелкните на файл в синхронизировать зрения-doublieclick сравниваем редактор показывает разницу между текущими файл и так оно и существовало, когда вы последний раз проверил или обновил его, в то время как конфликт редактирования сравнить диалоговое окно показывает различия между двумя источниками изменений (например, изменения, вы объединились против изменений, которые существовали в рабочей области, прежде чем слил).

во-вторых, вы можете знать об ошибке в некоторых версиях Eclipse subversive плагин, который вызывает все файлы, которые приняли изменения слияния неправильно помечены как имеющие конфликты. Эта ошибка была исправлена, но многие люди, похоже, еще не обновились, чтобы получить исправление. Более подробная информация здесь:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=312585

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

Если по какой-то причине вы не можете решить конфликты, вы можете SVN вернуться к проекту и вернуться к чистом состоянии, в противном случае вы делаете слияние на месте и как только вы закончите, вы можете совершить. Обратите внимание, что вам не нужно фиксировать, как только вы закончите обработку конфликтов, вы также можете вернуться в представление dev, проверить, что код компилируется, запустить модульные тесты, что угодно, а затем синхронизировать снова и фиксировать (как только конфликт будет локально разрешен, они не вернутся)

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

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

инструмент слияния openCollabNet для субклипа довольно аккуратный. Есть много доступных типов слияния, и слияние я только что выполнил с ним, когда легко. Рекомендую.

единственное, чего не хватает syncrhonize view в eclipse,-это возможность регистрации. В Team synchronization view я могу просматривать все свои изменения и разрешать конфликты, поэтому было бы интуитивно понятно регистрироваться прямо там, а не возвращаться к Java view и делать регистрацию.

Я приземлился здесь, потому что я искал способ слияния во внешнем редакторе слияния (KDIFF3), но начал слияние с eclipse. Ответы, приведенные выше, меня не удовлетворили. Итак, вот как настроить kdiff3 как редактор слияния и различий для SVN в eclipse:

перейти к Windows - > настройки → команда - > SVN - > Diff Viewer Добавить новую конфигурацию (кнопка Добавить): Расширение или тип mimetype: * - если вы хотите, вы можете указать разные типы mimetypes для разных редакторов, мне это не нужно альквантор.

Diff: Путь к программе C:\Program файлы\KDiff3\kdiff3.exe (или где у вас есть редактор слияния-sry для пути windows, не стесняйтесь добавлять версию linux в комментариях или редактировать этот ответ.)

Аргументы: ${base} ${mine} ${их}

слияние: Путь к программе C:\Program файлы\KDiff3\kdiff3.exe

Аргументы: ${base} ${mine} ${theirs} - o ${merged}

Это, вероятно, также будет работать для других редакторов слияния, но с другим синтаксисом аргумента (выясните это, дайте нам знать :) ).

использование как обычно (команда - > редактировать конфликты) для слияния и сравнения->foo для представления diff.

Ура