Я пытаюсь понять детали команд слияния subversion. Я думаю, что понимание различия между изменением, которое также является конфликтом, и изменение, которое не является конфликтом, помогло бы.
Это продолжение этой темы .
Я пытаюсь понять детали команд слияния subversion. Я думаю, что понимание различия между изменением, которое также является конфликтом, и изменение, которое не является конфликтом, помогло бы.
Это продолжение этой темы .
Изменение, которое является конфликтом, - это когда два человека сделали изменения в один и тот же файл таким образом, что эти два изменения не могут быть автоматически разрешены.
1) Давайте начнем с примера неконфликтного слияния.
Исходный файл
line1
line2
line3
Лицо A меняет его на это:
line1CHANGED
line2
line3
Лицо B меняет его на следующее:
line1
line2CHANGED
line3
Когда оба проверяются и сливаются, конфликт отсутствует, поскольку он может легко разрешить создание этого финального файла:
line1CHANGED
line2CHANGED
line3
Subversion будет обрабатывать это автоматически как слияние.
2) Теперь пример противоречивых изменений.
Исходный файл
line1
line2
line3
Лицо A меняет его на это:
line1CHANGED_BY_A
line2
line3
Лицо B меняет его на следующее:
line1CHANGED_BY_B
line2
line3
Это невозможно объединить автоматически, так что это конфликт. Вам необходимо будет решить, либо с помощью человека, либо сменить его, либо изменить человека. В этом случае subversion предупреждает вас о конфликтах и требует от вас решения о том, как их разрешать.
3) Наконец, вы можете иметь как конфликтующие, так и неконфликтные изменения в пределах одной и той же ревизии.
Исходный файл
line1
line2
line3
Лицо A меняет его на это:
line1CHANGED_BY_A
line2ALSO_CHANGED_BY_A
line3
Лицо B меняет его на следующее:
line1CHANGED_BY_B
line2
line3ALSO_CHANGED_BY_B
Теперь, в этом примере, оба человека изменили файл, и в строке 1 есть конфликтующее изменение, которое должно быть разрешено, но строки 2 и 3 являются неконфликтными изменениями и могут быть разрешены автоматически.
Вы можете решить эту проблему несколькими способами.
Во-первых, вы можете полностью принять файл A или B и отказаться от другого. Это приведет к тому, что другие лица потеряют противоречивые изменения. Скажем, вы решите полностью разрешить использование A, вашим окончательным файлом будет:
line1CHANGED_BY_A
line2ALSO_CHANGED_BY_A
line3
(Точно, файл и все изменения по B отбрасываются)
Во-вторых, вы можете разрешать только конфликтующие изменения и сохранять все неконфликтные изменения. Это вы выбрали бы либо изменение A или B для первой линии, и все равно получите обе другие изменения линии от обоих людей. Итак, скажем, например, вы решили разрешить конфликты, используя A, ваш конечный файл:
line1CHANGED_BY_A
line2ALSO_CHANGED_BY_A
line3ALSO_CHANGED_BY_B
Альтернативой вы можете использовать такие инструменты, как KDiff, которые поддерживают просмотр каждого конфликта отдельно (поскольку, конечно, вы можете иметь mutliple изменения, как конфликтующие и не конфликтующий, в том же файле), что позволит вам выбирать различные методы разрешения для каждого.
Если у вас возникли проблемы с пониманием слияния с инструментами командной строки, я настоятельно рекомендую вам взглянуть на KDiff (или какой-то другой инструмент слияния/разворота GUI), поскольку они отображают файлы рядом друг с другом (вместе с оригиналом) и позволяют вы должны визуализировать, что будет делать каждое действие разрешения.
Рассмотрим такую функцию (назовите ее ревизией 1)
void foo(){
int bar;
}
Теперь предположим, что два человека вносят изменения в эту функцию, начиная с версии 1.
Алиса:
void foo(){
char bar;
}
Боб:
double foo(){
double bar;
bar = 0;
return bar;
}
Для этого примера предположим, что Алиса совершает свои изменения.
Теперь Боб переходит на фиксацию изменений, и svn сообщит Бобу, что он устарел, и ему необходимо обновить и слить изменения. Итак, Боб запускает обновление, и происходит слияние.
В принципе, это (несколько) легко видеть, что происходит, это анализ, который решает, что Боб изменил из версии 1 и что Алиса изменила с пересмотра 1. Простое слияние приведет к чему-то вроде
double foo(){
[conflict] bar;
bar = 0;
return bar;
}
Обратите внимание, что и Алиса, и Боб изменили тип bar
на int
, за исключением того, что Алиса сделала его char
, а Боб сделал его double
. Слияние не может решить, какой из них правильный (он не выполняет анализ кода), так как человеческий Боб должен помочь разрешить конфликт.
Пример, конечно, несколько надуман, и, за исключением отмеченного конфликта, все остальные изменения не являются конфликтами.
Если бы Боб не изменил тип bar
, файлы слились бы без конфликта.