Это, кажется, очень простой вопрос, но я очень хочу узнать ответ. Я использую Subversion (SVN) для управления версиями, и я проверял все файлы, но клиент попросил меня создать правило в SVN, чтобы избежать проверки в папках bin и obj.
Почему я не должен проверять папки bin и obj?
Клиент также попросил меня оставить файл решения вне папки репозитория. Почему это?
Вы не должны добавлять временные файлы в SVN, они временные. Весь каталог obj состоит из файлов, созданных во время процесса сборки, и затем отбрасываются. (конечно, они остаются на диске, потому что некоторые из них повторно используются, например, кеш, когда исходные файлы не изменяются, но единственная причина, по которой они не удаляются после каждой сборки).
каталог bin - это немного другое дело. Можно добавить двоичные файлы в SVN, возможно, вы уже делаете это для файлов значков и изображений. Некоторые люди также добавляют встроенные двоичные файлы, что решение, зависящее от процессов управления конфигурацией, не отвечает "неправильным" ответам. Однако иногда ваш каталог bin может заполняться другими файлами, которые вы не хотите добавлять. Если вы создаете приложения .net, вы получите загрузку зависимых dll, скопированных в каталог bin, которые не являются строго частью вашего проекта. Добавление их просто раздувает ваш репозиторий без каких-либо преимуществ. Аналогично, в биндах есть поддерживающие двоичные файлы, такие как файлы символов debug debug.pdb. Они также не нужны.
Для файла решения я не уверен в вопросе, но если его не нужно проверять, это будет потому, что файл .sln является всего лишь "оберткой" для одного или нескольких файлов проекта. Его не требуется для создания проекта визуальной студии, поскольку новый будет создан по мере необходимости. Я думаю, ваши пользователи могут создавать свои собственные .sln файлы с различными группами проектов в них, делая каждый из них различным для каждого пользователя. Это было бы причиной для предотвращения проверок, поэтому каждый пользователь не перезаписывал бы друг другу настраиваемые файлы (хотя есть способы, чтобы пользователь мог предотвратить изменение файла, хранящегося в svn).
Итак, похоже, что ваша стратегия конфигурации не предполагает добавления каких-либо двоичных файлов в svn. В этом случае очень хорошая идея предотвратить это от случайного происшествия с крюком предварительной фиксации. Я также рекомендовал бы добавлять эти исключения к глобальным игнорированиям на стороне клиента, чтобы помочь вашим пользователям когда-либо пытаться добавить эти файлы в первую очередь.
"не должен" не распространяется на всех. Но в целом:
1) Не проверяйте двоичные файлы, которые могут быть сгенерированы из кода.
2) SVN - это система управления версиями исходного кода и не разработана с учетом двоичных файлов. Да, SVN и другие VCS могут обрабатывать двоичные файлы, но это не их целевая цель, особенно после точки 1)
3) Поскольку они генерируются вашим исходным кодом, они сильно изменятся и не похожи на библиотеки, которые редко меняются. Часто изменяющийся налог на двоичные файлы VCS, поскольку любой VCS не может правильно обрабатывать двоичные файлы, и вы, как правило, сохраняете больше с каждым изменением в двоичных файлах, поскольку разница (дельта) не так эффективна, как с исходным кодом.
Приступая к файлам решений (.sln), он идеально подходит для их проверки в репозиторий, хотя это и не совсем необходимо. Но большинство, если не все,.Net-проект - это Visual Studio на основе и даже для целей сборки, наличие .sln файла делает работу намного проще, поскольку вы можете вызывать msbuild в sln файле, а не в файлах csproj (или других проектов). Вы получаете другие преимущества, такие как правильная компиляция зависимостей, параллельная компиляция и т.д.
Вы не должны проверять какие-либо файлы, определенные пользователем или сгенерированные выходные файлы, так как каждый раз, когда вы делаете чек, вы должны усовершенствовать перекомпилированные выходные изменения. Я бы рекомендовал игнорировать bin, obj и .suo(not.sln) в качестве отправной точки, поскольку они будут воссозданы с компиляцией, а затем игнорируют любые другие, которые специфичны для пользователя или регенерируются с каждой сборкой.