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

Я пытаюсь изучить основы управления версиями Эриком Санком - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf

Сейчас я на странице 22. Я опишу сценарий для вас. Два пользователя на одном компьютере, harry и sally работают над файлом Lottery.c, который хранится в репо, называемом лотереей.

1 - Гарри фиксирует первый/начальный код. 2 - Салли меняет его и совершает. 3 - Пока 2 происходит, Харри внес изменения, но не совершил. 4 - Гарри совершает ошибку и получает сообщение об ошибке.

Transmitting file data .svn: Commit failed (details follow):
svn: File '/lottery.c' is out of date

5 - Чтобы исправить это, Харри обновит свою локальную копию, используя svn update.

Вот где у меня проблема! Автор говорит, что результат:

lottery harry$ svn update
G lottery.c
Updated to revision 2.

Но мой вывод:

lottery harry$ svn update
Updating '.':
C    lottery.c
Updated to revision 2.
Conflict discovered in file 'lottery.c'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options:

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

Ответы

Ответ 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 не знает, что делать. Теперь это ВАША работа, чтобы выполнить слияние.

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