Должны ли файлы проекта IDE находиться под контролем источника?

Ответ 1

Один простой вопрос: вам нужны они для создания кода? Если нет, то они являются артефактами, а не исходными файлами, и им не место в исходной системе управления.

Такие настройки, как настройки цвета вашего редактора или привязки клавиш, не являются частью системы сборки. Флаги компилятора и т.д.

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

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

Ответ 2

Мне проще и логично включать файлы проекта в репозитории, так как они являются частью самого проекта. Изменения проекта, файлы проекта тоже.

Всякий раз, когда вам нужно вернуть весь проект в предыдущее состояние или пригласить кого-то зарегистрироваться для работы над проектом, гораздо удобнее иметь каждый файл. Не только исходный код.

Кстати, большинство IDE включают файлы проекта в репозитории, и будет слишком больно исключать их и по-прежнему сохранять возможность проверить и проверить сами IDE.

Ответ 3

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

Ответ 4

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

Ответ 5

Как правило, файлы проекта должны контролироваться версиями, но файлы предпочтений пользователей следует игнорировать.

Например, при использовании Visual Studio файлы ".proj" и ".sln" должны контролироваться версиями, но ".suo" следует игнорировать.

Ответ 6

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

Ответ 7

Для .NET я думаю, что файлы проекта должны быть включены в репозитории управления версиями. В С# и VB это файл проекта, который определяет, какие исходные файлы являются частью сборки. Если вы добавите исходный файл в проект и не имеете файл проекта под контролем источника, все остальные разработчики в команде должны вручную добавить файл в проект THEIR.

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

Ответ 8

Мы используем Eclipse, и единственный файл, который мы проверим, является файлом .classpath, поэтому любые изменения в classpath не нарушают сборку обновления.

Ответ 9

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

Однако не все файлы проекта созданы равными, а некоторые - "помогающие файлы", которые хранят теги или недавно открывают файлы и т.д. Они не должны быть версиями, так как они могут варьироваться для каждого разработчика.

Существует два разных преимущества файлов проекта версии:

• легче развиваться. Специально для нового разработчика. Все, что вам нужно сделать, чтобы начать работать, это сделать заказ.
• другой должен иметь репродуктивную сборку. Wether сборка происходит от разработчика A или разработки B, результирующий объект тот же. Это ИМО является более важным преимуществом и является шагом на пути автоматизации строительства.

Ответ 10

Я работаю в компании, которая разрабатывает и продает IDE. Сначала мы удаляли все файлы проекта из пользовательских каталогов. Большинство людей были довольны этим способом. Но время от времени кто-то спрашивал, возможно ли это, потому что они хотели работать оттуда домашней системы и использовать контроль версий как быструю утилиту передачи файлов, синхронизирующую работу и домашний сайт.

Я могу сказать вам, что реализовать этот запрос было непросто!

Настройки должны быть четко разделены, например, если ваша IDE хранит координаты окна в файле настроек, и вы работаете на двух мониторах на работе и небольшой ноутбук дома, это действительно плохо. IDE также должна обеспечивать способ обработки расширения переменных среды в каждом пути к файлу. И, наконец, конечно, он должен иметь возможность указывать файлы личных имен или хранить их в разных местах - иначе вы скоро узнаете, что у трех разных разработчиков проекта есть 5 разных мнений о шрифтах, цветах, значениях по умолчанию и т.д., Потому что если это не очень хорошо, все они будут использовать одни и те же настройки.

С другой стороны, многие IDE имеют огромное количество данных для хранения, некоторые из них даже хранят настроенные графическим интерфейсом unit test случаи в настройках проекта. В этом случае, конечно, полезно повторно использовать файлы и проверить их в системе управления версиями.

Итак, вы видите, что это зависит. Попробуйте и посмотрите, как это работает для вашей среды.

Ответ 11

Да, я считаю, что файлы проекта IDE должны быть привязаны к Subversion, поскольку большинство из них включает в себя конфигурации о том, как создавать/компилировать проект.

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

Ответ 12

Не уверен, что это было упомянуто, но Visual Studio (по крайней мере, версия С++) создает два файла проекта:

• Общий файл проекта, содержащий структуру и настройки. Это необходимо для построения с помощью VS.
• Пользовательский файл проекта (обычно заканчивается именем пользователя и ПК). Это не требуется для построения, поэтому мы не включаем его в исходный элемент управления.