Слияние файлов vcproj - ад SCM - PullRequest
26 голосов
/ 16 декабря 2008

Объединение файлов проекта / решения - это известная катастрофа среди разработчиков / администраторов SCM, выполняющих слияния в своих системах контроля версий.

Возьмем, к примеру, общий сценарий: разработка выполняется над проектом / решением в двух разных ветвях. Когда приходит время слиться с основной линией разработки, существует очень небольшое сходство между VCPROJ (и SLN).

Причина в том, что Visual Studio может изменить (и ИЗМЕНИТ) расположение различных XML-подобных элементов в этих файлах. Например, конфигурации Debug и Release могут менять порядок при каждой операции сохранения в файле proj. Это делает невозможным легкое включение изменений из каждой ветви разработки, даже если не учитывать автоматическое объединение.

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

Сначала я хотел бы спросить: кто-нибудь нашел какой-нибудь элегантный способ обойти это?

Во-вторых, я хотел бы сделать два предложения:

  • Попросите Microsoft переопределить вышеуказанные файлы и ограничить их жестким упорядочением элементов.

  • найти инструмент (или написать один), который сортирует файлы vcproj (формат xml) и sln (формат sln ...) по алфавиту, рекурсивно (все элементы внутри элементов и т. Д.). Использование этого инструмента как для исходных, так и для целевых файлов позволит легко указать (и объединить) изменения, надеясь, что Visual Studio прочитает отсортированный, объединенный проект или файл SLN.

Любые другие идеи и мысли приветствуются.

Ответы [ 8 ]

4 голосов
/ 13 апреля 2009

Я создал инструмент для сравнения и слияния файла решения (http://slntools.codeplex.com). Гораздо проще объединить решение с инструментом, чем с «общим слиянием». Он не может обрабатывать файлы проекта.

3 голосов
/ 15 августа 2010

Project: Merge - это мой инструмент для сравнения и объединения файлов XML. Первоначально я написал его, потому что у меня возникла именно эта проблема с файлами проекта Visual Studio.

Он правильно определяет переупорядоченные элементы и / или атрибуты в файле XML и автоматически разрешает почти все «конфликты».

1 голос
/ 13 июня 2012

Проверьте параметры установки - убедитесь, что у всех ваших коллег установлен компонент компилятора x64 (или у всех нет)

1 голос
/ 25 июля 2010

Что мы делаем с файлами ресурсов (не так много проблем с файлами проекта), так это сортируем их перед объединением. Мы настроили команду слияния на Plastic для фактического запуска сортировки (другое приложение, которое мы разработали для этого, мы можем поделиться кодом, если вам интересно, ничего особенного) до слияния, поэтому все случайные перемещения исчезают. .. Надеюсь, это поможет.

1 голос
/ 16 декабря 2008

Я обычно стараюсь избегать помещения автоматически сгенерированных файлов в SCM. Автоматически сгенерированные файлы должны быть сгенерированы из исходных файлов, которые контролирует разработчик, и их можно поместить в SCM. Если определенный инструмент хранит данные в непрозрачном и хрупком формате, это проблема инструмента.

Что касается Visual Studio, хотя я думаю, что он имеет достойные компиляторы, библиотеки и среду отладки, я считаю, что файлы в генерируемых файлах (PRJ, SLN, RC) очень проблематичны. Помимо упомянутых вами проблем, они также сильно меняются в разных версиях VS. По этой причине мы пишем собственные make-файлы и собираем программы извне, используя make. Кроме того, мы разделяем файлы ресурсов на части, для которых мы вынуждены полагаться на VS, и те, которые мы можем разумно обрабатывать с помощью обычного редактора. Мы автоматически генерируем множество файлов ресурсов на основе высокоуровневого описания, написанного на пользовательских доменных языках. Таким образом, мы минимизируем влияние изменений, с которыми трудно справиться в рамках SCM.

1 голос
/ 16 декабря 2008

Возможно, вы захотите связать свой инструмент с триггером в вашей SCM (например, перехватить фиксацию для SVN), чтобы обеспечить повторный порядок в этих файлах.

Тогда у вас будет шанс эффективно объединить эти элементы.

0 голосов
/ 29 октября 2012

Существует проект 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 ...

0 голосов
/ 06 января 2011

Я написал небольшой Perl-скрипт для объединения файлов решений:
http://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-one/

Сценарий может быть изменен в соответствии с вашими потребностями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...