Слияние файлов vcproj - ад SCM
Слияние файлов проекта / решения - хорошо известная катастрофа среди разработчиков / администраторов SCM, выполняющих слияние в системе управления версиями.
Возьмем, к примеру, общий сценарий: разработка проекта / решения ведется в двух разных ветвях. Когда приходит время слиться обратно в основную линию разработки, между VCPROJ (и SLN) будет очень мало сходства.
Причина в том, что Visual Studio может изменить (и ДЕЙСТВИТЕЛЬНО меняет) расположение различных XML-подобных элементов в этих файлах. Например, отладка и выпуск конфигураций могут поменять местами порядок при каждой операции сохранения в файле proj. Это делает невозможным легкое включение изменений из каждой ветки разработки, даже не учитывая автоматическое слияние.
Я могу предположить, что Microsoft использует некоторую систему хеширования Perl для хранения структур vcproj, поэтому рендеринг файлов после операции сохранения не упорядочен.
Сначала я хотел бы спросить: нашел ли кто-нибудь какой-нибудь элегантный способ обойти это?
Во-вторых, я хотел бы сделать два предложения:
Попросите Microsoft повторно реализовать указанные выше файлы и ограничить их некоторым жестким порядком элементов.
найдите инструмент (или напишите его), который сортирует файлы vcproj (формат xml) и sln (формат sln ...) в алфавитном порядке, рекурсивно (все элементы внутри элементов и т. д.). Использование этого инструмента как для исходных, так и для целевых файлов позволит легко указать (и объединить) изменения, надеясь, что Visual Studio прочитает отсортированный, объединенный проект или файл sln.
Любые другие идеи и мысли приветствуются.
Насколько вы уверены, что порядок элементов в файлах решения не имеет значения? Скажем, в разделах ProjectSection (ProjectDependencies) и GlobalSection (TeamFoundationVersionControl)? Есть ли где-нибудь опубликованный формат?
Ответы 8
Возможно, вы захотите связать свой инструмент с триггером в SCM (например, перехватчиком повторной фиксации для SVN), чтобы принудительно изменить порядок в этих файлах.
Тогда у вас будет шанс эффективно объединить эти элементы вместе.
Обычно я стараюсь не помещать автоматически сгенерированные файлы в SCM. Автоматически сгенерированные файлы должны создаваться из исходных файлов, контролируемых разработчиком, и они могут быть помещены в SCM. Если конкретный инструмент хранит данные в непрозрачном и хрупком формате, это проблема инструмента.
Что касается Visual Studio, хотя я думаю, что у нее есть достойные компиляторы, библиотеки и среда отладки, я считаю, что файлы в генерируемых файлах (PRJ, SLN, RC) очень проблематичны. Помимо упомянутых вами проблем, они также сильно меняются между разными версиями VS. По этой причине мы пишем наши собственные make-файлы и собираем программы извне, используя make. Кроме того, мы разделяем файлы ресурсов на части, для которых мы вынуждены полагаться на VS, и те, которые мы можем разумно обрабатывать с помощью обычного редактора. Мы автоматически генерируем множество файлов ресурсов из высокоуровневого описания, написанного на специальных языках, специфичных для предметной области. Таким образом, мы минимизируем влияние изменений, с которыми трудно справиться в SCM.
Я создал инструмент для сравнения и объединения файлов решений (http://slntools.codeplex.com). Слить решение с инструментом намного проще, чем «обычное слияние». Он не может обрабатывать мысли о файлах проекта.
Я только что пробовал, но при сравнении проектов, редактировавшихся как VS, так и SD, выдает ошибки.
Что мы делаем с файлами ресурсов (не так много проблем с файлами проекта), так это сортируем их перед объединением. Мы настроили команду слияния на Plastic для фактического запуска сортировки (другое приложение, которое мы разработали для этого, мы можем поделиться кодом, если вам интересно, ничего особенного) перед слиянием, поэтому все случайные перемещения исчезнут. .. Надеюсь, поможет.
Проект: Слияние - мой инструмент для сравнения и объединения файлов XML. Первоначально я написал это, потому что у меня возникла именно эта проблема с файлами проекта Visual Studio.
Он правильно обнаруживает переупорядоченные элементы и / или атрибуты в XML-файле и автоматически разрешает почти все «конфликты».
Я написал небольшой Perl-скрипт для объединения файлов решений:
http://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-one/
Сценарий может быть изменен в соответствии с вашими потребностями.
Проверьте варианты установки - убедитесь, что у всех ваших коллег установлен компонент компилятора x64 (или у всех его нет)
Существует проект Google под названием gyp, который генерирует решения и проекты Visual Studio, очень похожие на CMake. Частью этого проекта являются инструменты Python для сортировки узлов xml и атрибутов файлов .sln и .vcproj соответственно: pretty_sln и pretty_vcproj. Вы можете скачать их самостоятельно с http://gyp.googlecode.com/svn/trunk/tools/
Я пока смотрел только на pretty_vcproj, он также расширяет файлы .vsprop, импортированные в vcproj, вероятно, для сравнения точного содержимого двух vcprojs. Полученный в результате vcproj не соответствует схеме, предоставленной Microsoft, но он, вероятно, будет работать нормально, или можно изменить его, чтобы только отсортировать узлы «Конфигурация» и «Платформа», оставив все остальное нетронутым. Не уверен, стоит ли это усилий, поскольку, похоже, уже есть другие проекты, направленные на нормализацию vcprojs ...
Мне нравится твоя идея с инструментом. мне кажется, это полезно иметь. Возможно, я попробую ...