Должен ли .sln быть привержен к контролю над источниками?

Question

Лучше ли фиксировать файл .sln в системе контроля версий? Когда это уместно или неуместно?

Обновление В ответах было несколько хороших моментов. Спасибо за ответы!

Answer 1

Я думаю, из других ответов ясно, что файлы решений полезны и должны быть зафиксированы, даже если они не используются для официальных сборок. Они удобны для тех, кто использует функции Visual Studio, такие как «Перейти к определению / объявлению».

По умолчанию они не содержат абсолютных путей или каких-либо других машинно-специфичных артефактов. (К сожалению, некоторые надстройки не поддерживают это свойство должным образом, например, AMD CodeAnalyst.) Если вы будете осторожны при использовании относительных путей в файлах проекта (как C ++, так и C #), они будут независимы от машины. тоже.

Вероятно, более полезный вопрос: какие файлы вы должны исключить? Вот содержимое моего файла .gitignore для моих проектов VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(Последняя запись предназначена только для профилировщика AMD CodeAnalyst.)

Для VS 2010 также следует исключить следующее:

ipch/
*.sdf
*.opensdf

Answer 2

Да - я думаю, что это всегда уместно. Пользовательские настройки находятся в других файлах.

Answer 3

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

Не содержит пользовательских настроек.

Answer 4

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

Answer 5

Я в целом согласен с тем, что файлы решений следует регистрировать, однако в компании, в которой я работаю, мы сделали что-то другое. У нас довольно большой репозиторий, и разработчики время от времени работают над разными частями системы. Для поддержки нашей работы у нас будет либо один большой файл решения, либо несколько меньших. Оба из них имеют несколько недостатков и требуют ручной работы со стороны разработчиков. Чтобы избежать этого, мы создали плагин, который обрабатывает все это.

Плагин позволяет каждому разработчику проверить подмножество дерева исходных текстов для работы, просто выбрав соответствующие проекты из репозитория. Затем плагин генерирует файл решения и изменяет файлы проекта на лету для данного решения. Он также обрабатывает ссылки. Другими словами, все, что нужно сделать разработчику, это выбрать подходящие проекты, а затем необходимые файлы будут сгенерированы / изменены. Это также позволяет нам настраивать различные другие параметры для обеспечения соответствия стандартам компании.

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

Answer 6

Да, вещи, которые вы должны совершить:

• раствор (* .sln),
• файлы проекта,
• все исходные файлы,
• файлы конфигурации приложения
• сценарии сборки

Вещи, которые вы должны не зафиксировать:

• файлы пользовательских параметров решения (.suo),
• сборка сгенерированных файлов (например, с использованием скрипта сборки) [Edit:] - только если все необходимые скрипты и инструменты сборки доступны под контролем версий (чтобы гарантировать, что сборки аутентичны в истории CVS)

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

Answer 7

Да, это должно быть частью системы контроля версий. Когда вы добавляете / удаляете проекты из своего приложения, .sln будет обновляться, и было бы хорошо иметь его под контролем исходного кода. Это позволит вам вытащить версии кода вашего приложения 2 назад и напрямую выполнить сборку (если вообще потребуется).

Answer 8

В большинстве случаев рекомендуется передать файлы .sln в систему контроля версий.

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

Answer 9

Да, вы всегда хотите включить файл .sln, он включает ссылки на все проекты, которые находятся в решении.

Answer 10

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