Действительно ли IDE должен спроектировать файлы быть подвергнутым управлению исходным кодом?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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