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

Возможно ли комбинировать следующие свойства, и если да, то как?Разрешение специфических для разработчика параметров в VS2008 Native C++-проектах

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

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

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

Любые другие предложения? Возможно ли это с VS2010?

источник

2011-01-08 Xavier Nodet

Для меня, похоже, есть принципиальное препятствие в этом: как вы будете решать, какие настройки должны быть разделены, и мы можем настроить на разработчика? VS 2005 имеет некоторые настройки (такие как пути отладки), хранящиеся в отдельном файле .opt, который обычно не контролируется версией. Я не уверен в более новой версии. – Suma

Лучшим было бы то, что каждый разработчик должен иметь возможность перезаписывать любые настройки, которые он хочет. Но первое, что приходит мне в голову, это libs для ссылки и include paths ... –

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

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

источник

2011-02-04 18:40:50

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

источник

2011-01-08 19:29:17 maxim1000

Это не вопрос тестирования новой библиотеки, а предоставление разработчикам некоторой свободы в своих проектах, не впутывая вещи другим ... –

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

По крайней мере, так я обрабатываю сам .hgignore.

источник

2011-02-03 13:02:02 Trass3r

Что бы я хотел, это иметь возможность отделить общую часть от отдельной части, чтобы Я могу совершить общую часть, когда мне нужно, без необходимости связываться с моими индивидуальными настройками. –

Да, я это понимал. Вот почему я назвал это предварительным решением. – Trass3r

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

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

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

источник

2011-02-08 10:34:54 LeGEC

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

ответ

Смежные вопросы