Svn Merge From Branch to Trunk Не удаляя ствол (или его историю)

Question

Svn Merge From Branch to Trunk Не удаляя ствол (или его историю)

1

Я создал филиал, на него было внесено множество изменений. Между тем, некоторые изменения были сделаны и в багажнике. Таким образом, я создал новую ветку и вручную объединил ревизии в туловище к вновь созданной ветке, потому что ветвь имеет серьезные изменения, тогда как изменения ствола относительно минимальны.

Теперь я должен заменить багажник новой веткой. Я видел различные сообщения, предлагающие удалить сундук. Но это не приемлемое решение для меня, у сундука есть изменения файла с самого начала, я не хочу их потерять. Когда я пытаюсь объединить сундук и новую ветвь в Eclipse, он прерывается ненормально.

При проверке файлов, помеченных как конфликт, последние изменения из ветки не отображаются должным образом в окне сравнения (файл с именем filename.java.2.working содержит последние изменения ветвей, но этот файл не отображается в окне сравнения в eclipse),

Кто-нибудь знает решение заменить багажник веткой, не удаляя багажник?

Например: Филиал, созданный по версии 12121.

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

Vijay 28 март 2014, в 15:51

Источник

Теги:

java

eclipse

merge

svn

tortoisesvn

1 ответ

Ещё вопросы

Slav · Answer 1 · 2014-03-28T13-50-00.000Z

TL; DR: вы не можете удалить местоположение SVN и назначить его историю в другое место, даже если они названы одинаковыми. То, что вы можете сделать, это слить в нужное место и сохранить всю оригинальную историю.

Теперь позвольте мне понять это прямо:

У вас есть trunk.
У вас есть ветвь с большими изменениями branch A
Теперь у trunk есть некоторые незначительные изменения.
Вы создали новую branch B от branch A? На самом деле непонятно, что вы создали branch B
Вы объединили изменения trunk в branch B
Теперь вы хотите, чтобы branch B стала вашей trunk (другими словами, вам нужно объединить целую branch B в trunk)

Почему бы вам просто не слить эти незначительные изменения с trunk на branch A напрямую, тем самым сохранив ветвь в синхронизации, а затем реинтегрировать branch A в trunk? Предполагается, что ваша функциональная ветка синхронизируется с сундуком на ежедневной основе, чем чаще, тем лучше. Единственный раз, когда вы не должны синхронизировать ветку, - это когда это ветвь релиза, и вы не хотите, чтобы в ней были изменения. Но из вашего вопроса вы хотите, чтобы изменения в trunk в branch A, нет?

branch B кажется полностью избыточной здесь. Я ничего не знаю об Eclipse, но, вероятно, это не так, потому что branch B не является прямым потомком из trunk.

Выполнение:

Объединить branch A в trunk

устанавливает тот же эффективный результат, что и выполнение:

Создать branch B от branch A
Слияние trunk с branch B
Слейте branch B обратно в trunk чтобы сохранить историю trunk

Сложность слияния между " branch A → trunk " идентична сложности слияния между " trunk → branch B (которая аналогична branch A)"

Просьба указать ваши причины существования branch B, возможно, я совершенно не понимаю здесь.

Что вы должны сделать:

Проверьте trunk или обновите существующий заказ
Используя TortoiseSVN (потому что вы связали это, и я не знаю Eclipse), щелкните правой кнопкой мыши на trunk, выберите TortoiseSVN → Merge
Нажмите "Далее", укажите URL-адрес branch A
Нажмите " Show Log, выберите все изменения, которые хотите объединить, или вы можете указать диапазон с 12121-12777
Нажмите " Next
Нажмите " Merge
Разрешать конфликты, если таковые имеются.
Соедините trunk с SVN.

Вышеприведенная фиксация в SVN ясно покажет, что эти изменения произошли от Branch A

Если есть конфликты, вы должны решить их, используя любой инструмент настройки, который вы настроили. Этот файл filename.java.2.working о котором вы упомянули, является файлом разрешения конфликтов. Когда SVN обнаруживает конфликты между двумя файлами, которые он не может автоматически разрешить, он предоставит вам копию "вашего" файла, копию "их" файла и файл "merge". Вы выбираете-n-выбираете между "вашими" и "их" файлами в "файл слияния", а затем отмечаете конфликт как разрешенный. После того как отмеченные "разрешены", все 3 удаляются с рабочего места и заменяются исходным именем файла, содержащим содержимое "объединенного" файла. Это то, что затем происходит.

Быстрая и грязная в вашей ситуации:
Учитывая, что вы уже создали резервную branch B и уже объединенную trunk измененную на branch B, и теперь хотите, чтобы branch B стала вашей новой trunk, вы можете сделать следующее быстро и грязно

Проверьте trunk или обновите существующий заказ
В файловой системе щелкните правой кнопкой мыши папку вашего branch B, выберите TortoiseSVN → Export и экспортируйте в новую папку
Скопируйте все файлы из новой папки, в свою trunk кассу (перезапись)
Зафиксировать trunk

Вышеуказанное будет отображаться как прямая фиксация и не покажет, что изменения произошли из branch B

И, наконец:
Eg: Branch created at version 12121 Trunk latest 12500 Branch latest 12777. Now when я do the merge, я want all the files to be committed at version 12501 in trunk.
Выше невозможно, так как любая новая фиксация в любом месте SVN (любой соединительной 12778 или ветки) будет иметь ревизию 12778 или выше. Также обратите внимание, что это ревизия, в SVN нет такой версии, как версия, и вы не можете думать о "ревизиях" как о "версии", это не одно и то же.