2013-05-13 2 views
3

Я работаю с кодовой базой, которая (исторически) была объединена вручную, а не через svn merge. Я пытаюсь изменить это доказать всем, насколько полезным является слияние - но когда я делаю сухой бег, я получаю это:svn merge --dry-run Показать svn diff

$ svn merge [[Repo URL]] . -c 21355,21358,21364,21370,21371,21373 --dry-run 
--- Merging r21355 into '.': 
U [[File 1]] 
--- Merging r21355 into '[[dir]]': 
U [[dir]]/[[File 2]] 
U [[dir]]/[[File 3]] 
--- Merging r21358 into '[[dir]]': 
U [[dir]]/[[File 4]] 
--- Merging r21364 into '[[dir]]': 
U [[dir]]/[[File 2]] 
C [[dir]]/[[File 4]]  
--- Merging r21370 into '[[dir]]': 
U [[dir]]/[[File 5]] 
--- Merging r21371 into '[[dir]]': 
U [[dir]]/[[File 5]] 
--- Merging r21373 into '[[dir]]': 
C [[dir]]/[[File 5]] 
U [[dir]]/[[File 6]] 
Summary of conflicts: 
    Text conflicts: 2 

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

Я проверил новую рабочую копию только в узком каталоге, и когда я побежал слияние без всухую, я получил:

--- Merging r21355 into '.': 
U [[File 3]] 
--- Merging r21358 into '.': 
U [[File 4]] 
--- Merging r21364 into '.': 
G [[File 4]] 
--- Merging r21370 into '.': 
U [[File 5]] 
--- Merging r21371 into '.': 
G [[File 5]] 
--- Merging r21373 into '.': 
G [[File 5]] 

(файлы 1, 2 и 6 находятся в другом месте)

Итак, теперь я особенно смущен - сухой запуск сообщает о конфликте, но когда слияние фактически запущено, это успешно? Это намеренное поведение? Я признаю, что я не мастер SVN, но я остался в замешательстве.

+0

Я могу воспроизвести эту проблему с двумя ревизиями. В Rev 7 добавлен файл, а rev 8 изменяет файл. Получают одинаковые результаты команды 'svn merge -r6: 8' и' svn merge -c7,8'. Однако, если я добавлю опцию '--dry-run', первая успешно завершится, а последняя не удастся. Звучит как ошибка в SVN 1.7. – nosid

+0

@nosid Я бегу 1.6.3 – FrankieTheKneeMan

ответ

1

Ожидается поведение для --dry-run, которое не изменяет файловую систему.

Поскольку вы указали отдельные изменения, эти изменения применяются отдельно, один за другим. G в выводе слияния означает, что произошло слияние - svn внесла изменение в файл, у которого уже было локальное изменение.

Подробно:

  • r21358 модифицирует файл 4.
  • В обычном слиянии, File-теперь имеет локальные изменения и r21364 объединяет эти изменения вместе, потому что разница соответствует текущему состоянию файла.
  • В сухом режиме файл 4 не был изменен r21358. Файл не соответствует тому, что ожидает следующая ревизия, r21364, так что вместо этого вы получаете конфликт.
  • То же самое происходит с r21373 - либо r21370, либо r21371 изменил ту же часть файла, к которой он относится.
  • r21371 не страдает от этого, потому что он затрагивает другую часть файла 5, чем r21370.

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

+0

Я думаю, это то, что технически происходит, но я думаю, что это ошибка, а не ожидаемое поведение. [Этот вопрос] (http://subversion.tigris.org/issues/show_bug.cgi?id=2584), помеченный как фиксированный относительно удаленных и повторно добавленных файлов, кажется, указывает, что 'merge -dry-run 'должен функционировать ТОЧНО как« слияние », просто не меняя никаких файлов. '-dry-run' должен быть инструментом, который позволяет вам проверять эти проблемы, прежде чем столкнуться с ними. – FrankieTheKneeMan

Смежные вопросы