TFS vNext: новый merge

Продолжаем рассказ о замечательных нововведениях, начатый мной постом Революция в модели Source Control TFS 11 – Local Workspaces.

Сегодня пойдёт речь о слиянии изменений (merge). Согласитесь, это одна из самых сложных задач в управлении системой контроля версий, которая очень редко когда обходится без участия человека.

Посмотрим, какие три основных улучшения нас ожидают в следующей версии.

Сразу хочу предупредить – я не держал в руках последний билд, Помня о многочисленных просьбах предоставлять информацию на русском языке, я привожу свой вольный пересказ статьи Брайана Харри “Merge enhancements in TFS 11”.

Новый инструмент diff/merge.

Ни для кого не секрет, что нынешняя сравнивалка изменений приехала к нам из SourceSafe. Практически без каких либо изменений она прожила в TFS 2005, TFS 2008 и в TFS 2010. Фактически, она пришла к нам из 1994 года. Настала пора изменений. Вот, что появилось в Dev 11:

• Поддержка двух режимов просмотра – “встроенный”, при котором изменённые строки показываются друг под другом, и “рядом”, при котором два текста показываются рядом.
• Подсветка синтаксиса – всё, как в стандартном редакторе.
• Выделение изменений внутри одной строки.
• Возможность полноценного редактирования в любом режиме сравнения или слияния, с использованием всей мощи редактора – undo, intellitrace и т.п.
• Мини-карта при сравнении.
• Стало доступно больше контекстных действий, таки, как history, и т.п.
• Окно интегрируется в новую инфраструктуру управления окнами в IDE.
• Улучшенные возможности по выбору решений для результатов слияния конфликтов.
• Интерактивная возможность включения и выключения пропуска “пробелов”.

Посмотрите, как это выглядит:

То же, только во “встроенном” режиме:

Также, три различных режима для слияния изменений:

В общем и целом – значительное улучшение!

Уменьшение конфликтов при слиянии

Наверное, самое большое количество жалоб приходилось слышать разработчикам на то, что процесс слияния сложен и громоздок. В процессе сложного анализа, пришли к пониманию того, что корень недовольства заключается в большом количестве предлагаемых для разрешения конфликтов, которые, на самом деле, не требуют принятия каких-то значимых решений. Выяснилось, что в подобных случаях люди просто хотят автоматической обработки всех очевидных случаев и сосредоточить своё внимание на местах, которые действительно требуют участия человека. Рассмотрим 48 изменений файлов в исходной ветке и 90 изменённых файлов в конечной ветке. Результат конфликтов в отчёте:

• TFS 2010: 38 конфликтов
• TFS 11: 12 конфликтов

Т.е. разницу в 26 конфликтов TFS 11 разрешил автоматически без привлечения человека.

<рекламная пауза>

О том, как новый TFS выигрывает у Git в борьбе за качественное слияние, читайте в оригинальной статье.

</рекламная пауза>

Кстати, действительно выигрывает.

Baseless merge из UI

Извините, не смог подобрать русского термина. Пример. Начнём со структуры, которая выглядит так:

Как Вы можете видеть у destination и AlternateDestination нет прямой связи. Не трудно представить такой сценарий, при котором Вам захочется пронести изменения из destination в AlternateDestination минуя Source. Запускаем Source Control Explorer  и начинаем обыкновенное слияние:

Как и обычно, только Source присутствует в списке. Однако, в отличие от TFS 2010 теперь появилась кнопка Browse. Если её нажать, то можно выбрать путь внутри системы контроля версий:

в том числе и AlternateDestination:

Вас, конечно, предупредят о том, что это baseless merge, но кнопку Next нажать дадут.  

Merge при unshelve

В начале разработчики очень любили “откладывать изменения на полочку”. Очень хороший способ организации однотипных изменений. Однако, в повседневной жизни возникают жалобы на то, что после “вылёживания” на полке изменения нельзя с неё забрать, так как в рабочем пространстве уже присутствуют конфликты и это является серьёзным ограничением. Но не в Dev11! Теперь функциональность слияния интегрирована в операцию “снятия с полки”.

Следите за продолжениями.