Почему я не должен проверять папки bin и obj в SVN?

Question

Кажется, это очень простой вопрос, но мне не терпится узнать ответ. Я использую Subversion (SVN) для контроля исходного кода и проверяю все файлы, но клиент попросил меня создать правило в SVN, чтобы избежать проверки в папках bin и obj.
Почему я не должен проверять папки bin и obj в?

Клиент также попросил меня сохранить файл решения вне папки репозитория. Почему это так?

Answer 1

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

каталог binэто немного другое дело.Можно добавить двоичные файлы в SVN, вы, вероятно, уже делаете это для файлов значков и изображений.Некоторые люди также добавляют встроенные двоичные файлы, это решение, которое зависит от ваших процессов управления конфигурацией, нет «неправильного» ответа.Однако иногда ваш каталог bin может быть заполнен другими файлами, которые вы не хотите добавлять.Если вы создаете приложения .net, вы получите множество зависимых библиотек, скопированных в каталог bin, которые не являются строго частью вашего проекта.Добавление их просто раздувает ваш репозиторий без пользы.Точно так же в bin имеются поддерживающие двоичные файлы, такие как файлы символов отладки .pdb.Они на самом деле не нужны.

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

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

Answer 2

«не должен» не относится ко всем.Но обычно:

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

2) SVN - это система управления версиями исходного кода, не разработанная с учетом двоичных файлов.Да, SVN и другие VCS могут обрабатывать двоичные файлы, но это не их предназначение, особенно после пункта 1)

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

Приход к решению(.sln) файлов, это идеальный вариант, чтобы зарегистрировать их в хранилище, хотя и не обязательно.Но большинство, если не все, проекты .Net основаны на Visual Studio и даже для целей сборки, наличие файла .sln значительно облегчает работу, так как вы можете вызывать msbuild для файла sln, а не для файлов csproj (или другого проекта).Вы получаете другие преимущества, такие как правильная компиляция зависимостей, параллельная компиляция и т. Д.

Answer 3

На самом деле вы не должны регистрировать какие-либо пользовательские файлы или сгенерированные выходные файлы, так как каждый раз, когда вы делаете проверку, вы будете возобновлять перекомпилированные выходные изменения. Я бы порекомендовал игнорировать bin, obj и .suo (не .sln) в качестве отправной точки, так как они будут воссозданы при компиляции, а затем игнорировать любые другие, специфичные для пользователя или восстанавливаемые при каждой сборке.