Разрешение конфликта слияния при обновлении svn

Ответ 1

Когда у вас есть несколько человек, меняющих один и тот же файл одновременно, очень возможно, чтобы оба изменили одни и те же строки. Вот что с тобой случилось. Салли меняет те же строки, что и Гарри. Когда Гарри сделал svn update, Subversion обнаружил это и спрашивает, что делать.

Предупреждение: иногда Subversion ищет различия в строке между вашей версией и их версией, а не значимые различия. Например, если отступ строки был изменен или интервал был другим, или если вы изменили окончание строки, Subversion объявит это как конфликт, хотя, вероятно, это не так. Возможно, почему книга не нашла эту проблему, но вы это сделали. Не означает, что вы сделали что-то не так.

Что делать? Subversion дает вам несколько вариантов.

• отложить p: Это то, что я обычно делаю с этим типом ситуации. Subversion будет внедряться в файлы diff-маркеров, которые выглядят как в файле:

<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx

Это показывает вам изменения в ревизии rxxx (что сделала Салли), похожее на изменения, которые у вас есть (Гарри меняется). Обычно изменения незначительны, что довольно легко понять, что делать.

• показать diff df: Это покажет вам различия между вашими изменениями (Гарри) и тем, что в другой редакции (Sally's). В основном это показывает маркеры различий.
• edit e: вы можете редактировать конфликт слияния, как вы делаете слияние, а не ждать дольше.
• merge m: Не слишком уверен, что это делает. Вы делаете слияние прямо сейчас, поэтому это не имеет особого смысла.
• их сторона конфликта tc: Примите то, что сделала Салли, чтобы разрешить конфликт. Вероятно, вам придется переделать свои изменения, но по крайней мере вы рассматриваете изменения Салли.
• моя сторона конфликта mc: Самый опасный сценарий, потому что вы полностью игнорируете изменения Салли. Салли сделала исправление, и вы, возможно, отменили его. Когда выйдет релиз, а Sally fix не будет в нем, вас обвинят в том, что вы удалите это изменение. Итак, почему вы это делаете? Потому что вы уже посмотрели на изменения и поняли, что конфликт действительно не был конфликтом. Это было изменение в отступе или что-то подобное. Или вы вызвали переменную increment, и Салли назвала ее counter.

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

Как только вы исправите проблему, вы делаете svn resolved в этом файле, чтобы Subversion узнала, что вы исправили конфликт.

Есть еще один выбор - например, вы можете запустить сторонний инструмент diff/merge для обработки конфликта.

За дополнительной информацией обратитесь к руководству Subversion on line о разрешении конфликтов слияния.

Ответ 2

Если вы выберете опцию s, она покажет вам:

(e)  edit             - change merged file in an editor
(df) diff-full        - show all changes made to merged file
(r)  resolved         - accept merged version of file

(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict    - accept my version for all conflicts (same)
(tc) theirs-conflict  - accept their version for all conflicts (same)

(mf) mine-full        - accept my version of entire file (even non-conflicts)
(tf) theirs-full      - accept their version of entire file (same)

(p)  postpone         - mark the conflict to be resolved later
(l)  launch           - launch external tool to resolve conflict
(s)  show all         - show this list

Используйте dc, чтобы просмотреть конфиги, затем вы можете выбрать лучший вариант для использования

Ответ 3

"G" указывает, что файл был изменен кем-то другим, но изменения, внесенные этим человеком, были в другой части файла, поэтому SVN мог объединить его для вас, не обращаясь за помощью.

"C" указывает, что не только файл был изменен кем-то другим, но их изменения были в тех же строках, которые вы также изменили, поэтому SVN не знает, что делать. Теперь это ВАША работа, чтобы выполнить слияние.

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