Разрешение специфичных для разработчика настроек в проектах VS2008 Native C ++

Question

Можно ли объединить следующие свойства, и если да, то как?

• Храните в нашей системе управления версиями некоторые файлы проектов Visual Studio 2008 для C ++ (VCPROJ) для разработчиков в нашей команде, использующих эту IDE.
• Разрешить некоторым из этих разработчиков настраивать свои проекты (например, использовать отладочную версию сторонних библиотек вместо обычных).
• Убедитесь, что эти изменения сделаны в файлах, которые не имеют версий.

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

Кажется, что «файловый подход VSPROP» обречен на неудачу, поскольку VS2008 отказывается загружать проекты, которые ссылаются на несуществующие файлы VSPROP ...

Любое другое предложение? Это возможно с VS2010?

Answer 1

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

Answer 2

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

Отчасти отвечает вашим потребностям:

• Преимущество: у нас есть способ сохранить общую конфигурацию для всех, и нет случайной фиксации локальной конфигурации
• Недостаток: слепое копирование файлов фактически уничтожает локальные изменения. Мы живем с этим. Мы могли бы написать более умный инструмент слияния (используя diff или манипуляции, специфичные для xml), но не хотим тратить много времени на поддержку инструментов развертывания.

Answer 3

Что ж, в качестве предварительного решения вы можете поместить файл проекта в нечто вроде .hgignore или .gitignore после его начальной фиксации. Таким образом, изменения не могут быть сделаны случайно.

По крайней мере, так я обращаюсь с самим .hgignore.

Answer 4

Ветви могут решить эту проблему: вы создаете ветку, играете с различными версиями сторонних разработчиков, объединяете изменения в ствол, если результаты хороши.