Предложения по ведению файлов проекта Visual Studio vcproj в системе управления версиями

Question

Microsoft Visual Studio использует XML для сохранения файлов проекта .vcproj. Таким образом, различие XML-файлов проекта должно быть легко.

К сожалению, если вы измените какое-либо из свойств файла проекта, Visual Studio настаивает на случайном перемешивании узлов XML файла проекта! Это делает текстовое различие и объединение изменений файла проекта в принципе невозможным. Изменение одного параметра компилятора может заставить мой инструмент визуального сравнения думать, что я изменил 50% строк в файле! Я даже попробовал некоторые инструменты XML diff, но они просто показывают более структурированное представление о том же беспорядке.

Есть ли у кого-нибудь предложения по ведению файлов .vcproj в системе контроля версий? Или способ убедить Visual Studio , а не переставить узлы XML в файле .vcproj?

(Я также исследовал использование таких инструментов, как CMake, для создания файлов .vcproj из более удобного для сравнения текстового файла, но у CMake есть свои проблемы.)

Answer 1

Кажется, что это время от времени возникает.

• Объединение файлов vcproj - ад SCM

Возможно, это проблема для плагина или другого нормализующего инструмента.

Это был бы большой побочный бизнес, пока MS не решит это исправить. Тогда вам не повезло - если, конечно, они не предлагают купить ваш IP.

Кто-нибудь хочет начать проект с открытым исходным кодом или коммерческий продукт? Я игра.

Я мог бы попробовать автономный инструмент нормализации, а затем посмотреть, смогу ли я превратить его в плагин.

Answer 2

Мы видим это здесь, на работе сейчас, с файлами проектов, где конфигурации переупорядочиваются на компьютерах нескольких народов, и это очень расстраивает ...

* Примечание: Мы все используем VS 2008 Pro, а не Team

Сначала кажется, что они случайным образом переупорядочены, но на самом деле существует шаблон , и он вовсе не случайный.

Для одной группы конфигурации упорядочены по платформе, а затем по конфигурации:

• Debug | Win32
• Debug | 64
• Release | Win32
• Release | x64
• Debug DX11 | Win32
• Отладка DX11 | x64
• Выпуск DX11 | Win32
• Выпуск DX11 | x64
• ...

Для другой группы конфигурации упорядочены по Config, а затем по платформе:

• Debug | Win32
• Release | Win32
• Debug DX11 | Win32
• Выпуск DX11 | Win32
• Debug | 64
• Release | x64
• Отладка DX11 | x64
• Выпуск DX11 | x64
• ...

Просматривая историю выступлений, это согласуется с несколькими проектами, представленными одними и теми же группами людей, и существует примерно 50/50, поэтому это происходит не только для одного человека.

Это та же самая проблема, которую вы все видите? Если это так, я надеюсь, что этот шаблон поможет найти решение, не включающее шаг макроса / дополнительного различий ...

Это должен быть параметр где-то или побочный эффект нажатия чего-либо, поскольку он воспроизводится на 100% для каждой из этих машин. Даже если это что-то глупое, например, какой вариант вы выберете для своего начального макета среды (VC ++, VB, General Development, ect ...)

Answer 3

Я использую WinMerge в качестве моего diff-инструмента, и я включил обнаружение перемещенного блока. Это не совсем решает проблему, но делает визуализацию различий более терпимой.

Answer 4

Я думаю, что нашел причину этой случайности. По крайней мере, в VS2008.

Если вы установите компиляторы x64, VS упорядочит проекты как:

Debug|Win32
Debug|x64
Release|Win32
Release|x64

Если вы этого не сделаете, он закажет их как:

Debug|Win32
Release|Win32
Debug|x64
Release|x64

Поэтому убедитесь, что на всех ваших пирах установлен один и тот же набор компиляторов, чтобы он не перемешивался.

Проверено, и это поведение представляется воспроизводимым.

Answer 5

Моя команда в Adobe видела то же самое в vs2008. Проект win32 / win64, представляющий собой простой Debug / Release, предоставляет вам 4 конфигурации и случайное перемешивание. Несколько человек пытались выяснить, когда и почему devstudio переупорядочивает, но в настоящее время мысль о том, что ключ сортировки - это хэш ключевого слова, а значит, полуслучайный. Мы отказались и в обзорах кода просто суммируем «реальные» изменения.

Answer 6

В какой версии Visual Studio вы это видите?

Я много работаю с файлами .vcproj (мы поддерживаем версии файлов проекта для наших библиотек в нескольких версиях Visual Studio, и я всегда анализирую и объединяю их), но я никогда не видел такого поведения.