TFS: Слияние назад в основное ответвление

Что говорится в итоговом сообщении, когда вы нажимаете «Разрешить отдельный конфликт»? Если ваши слияния из Current -> Experimental были выполнены без серьезной ручной работы, это должно быть что-то вроде «X source, 0 target, Y both, 0 конфликтующих». Другими словами, в целевом (текущем) файле нет блоков содержимого, которых еще нет в копии исходной ветви (экспериментальный). Вы можете безопасно использовать кнопку AutoMerge All.

Примечание: AutoMerge должен быть безопасным в любом случае. Он оптимизирован так, чтобы быть консервативным в отношении ранних предупреждений, а не для способности решать каждый случай. Но я понимаю, что многие из нас, в том числе и я, любят запускать инструмент слияния, когда возникают какие-либо вопросы. В описанном сценарии, IMO, даже самые пугливые могут отдыхать спокойно.

Почему вообще возникает конфликт? А что, если итоговое сообщение не так банально? Рад, что вы спросили :) Краткий ответ - потому что вычисление, которое определяет общего предка («базу») связанных файлов, сильно зависит от того, как были разрешены предыдущие конфликты слияния между ними. Простой пример:

1. настроить две ветви, A и B.
2. внести изменения в A \ foo.cs и B \ foo.cs в отдельных частях файла
3. объединить A -> B
4. AutoMerge конфликт
5. слияние B -> A

TFS должна пометить эту последовательность событий как конфликтующую. Ближайший общий предок между B \ foo.cs; 4 и A \ foo.cs; 2 находится на шаге 1, и с тех пор обе стороны, очевидно, изменились.

Заманчиво сказать, что A и B синхронизированы после шага 4. (Точнее: общий предок для шага 5 ' s merge - это версия №2). Несомненно, успешное слияние контента означает, что B \ foo.cs содержит все изменения, внесенные на сегодняшний день? К сожалению, есть ряд причин, по которым вы не можете этого предполагать:

• Общее: не все конфликты можно объединить с помощью AutoMerged. Вам нужны критерии, применимые к обоим сценариям.

• Правильность: даже когда AutoMerge завершается успешно, он не всегда генерирует допустимый код. Классический пример возникает, когда два человека добавляют одно и то же поле в разные части определения класса.

• Гибкость: у каждого пользователя системы управления версиями есть свои любимые инструменты слияния. И им нужна возможность продолжить разработку / тестирование между первоначальным решением Resolve [«когда-нибудь необходимо объединить содержимое»] и окончательной проверкой [«здесь, это работает»].

• Архитектура: в централизованной системе, например TFS, сервер просто может не доверять чему-либо, кроме своей собственной базы данных + требованиям проверки API. Пока входные данные соответствуют спецификации, серверу не следует пытаться различать , как выполнялись различные типы слияния контента. (Если вы думаете, что сценарии до сих пор легко различимы, подумайте: что, если в движке AutoMerge есть ошибка? Что, если мошеннический клиент вызывает веб-сервис напрямую с произвольным содержимым файла? Здесь только поверхностно ... серверы должны быть скептически настроены по какой-то причине!) Все, что он может безопасно вычислить, это , вы отправили мне результирующий файл, не соответствующий исходному или целевому .

Сложив эти требования вместе, вы получите дизайн, действия на шаге 4 в довольно широкую категорию, которая также включает ручное объединение в результате перекрывающихся правок, содержимое объединяется [автоматически или нет], предоставляемое сторонними инструментами, и файлы редактируются вручную после факта. В терминологии TFS это разрешение AcceptMerge . Будучи записанными как таковые, Правила слияния (tm) должны предполагать худшее в погоне за исторической целостностью и безопасностью будущих операций. В процессе ваши семантические намерения для шага 4 («полностью включить в B каждое изменение, которое было внесено в A в # 2») были упрощены до нескольких байтов чистой логики («дать B следующее новое содержимое + кредит за обработку # 2 "). К сожалению, это «просто» проблема UX / образования. Люди сильно злятся, когда правила слияния делают неверные предположения, которые приводят к поломке кода и потере данных. Напротив, все, что вам нужно сделать, это нажать кнопку.

FWIW, у этой истории есть много других концовок. Если вы выбрали Копировать из исходной ветки [также известный как AcceptTheirs] на шаге 4, на шаге 5 не будет конфликта. То же самое, если вы выбрали разрешение AcceptMerge, но случайно зафиксировали файл с тем же хешем MD5, что и A \ foo.cs; 2 . Если вместо этого вы выберете Keep Target [aka AcceptYours], последующие последствия снова изменятся, хотя я не могу вспомнить детали прямо сейчас. Все вышеперечисленное становится довольно сложным, когда вы добавляете другие типы изменений (особенно Rename), объединяете ветки, которые гораздо более несинхронизированы, чем в моем примере, вишня выбирает определенные диапазоны версий и обрабатывает сироты позже и т. Д.

РЕДАКТИРОВАТЬ: по воле судьбы, кто-то другой задал точно такой же вопрос на форуме MSDN. Как это обычно свойственно мне, я написал им еще один длинный ответ, который оказался совершенно другим! (хотя, очевидно, затрагивая те же ключевые моменты) Надеюсь, это поможет: http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/e567b8ed-fc66-4b2b-a330-7c7d3a93cf1a