SVN и двоичные файлы

Question

Задав этот вопрос мне посоветовали не проверять двоичные файлы в subversion. Тогда у меня вопрос, что мне делать со сторонними dll, которые должны быть в папке bin? Мне нужно иметь возможность проверить рабочую копию и запустить ее как веб-сайт со всеми dll и т. Д. Без изменений.

Answer 1

Ответы на ваш другой вопрос предполагают, что вы не отправляете сгенерированные файлы в Subversion. Библиотеки DLL в папке bin часто создаются как часть приложения, поэтому они должны быть регенерированы, а не сохранены в Subversion.

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

Answer 2

Я всегда проверяю сторонние библиотеки DLL (в папке 'lib'), чтобы приложение могло собираться и запускаться из новой проверки. Я думаю, что правило «не проверять двоичные файлы» применяется к двоичным файлам, которые генерируются из исходного кода, который вы зарегистрировали.

Answer 3

Рекомендации просты:

• Все, что требуется для перестройки решения, должно быть проверено в *
• Все, что генерируется в процессе сборки - должно оставаться вне

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

Answer 4

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

Answer 5

Как сказал Бен. Я не помещаю двоичные файлы, которые будут часто меняться, в систему контроля версий. Но третья часть dll, да, они также попадают в папку lib на моем svn.

Answer 6

Если под двоичными файлами вы подразумеваете исполняемые файлы, лучше всего восстанавливать их из источника - если источник доступен. Если под двоичными файлами вы подразумеваете нетекстовые файлы, я могу вам сказать, что я все время использую SVN для хранения нетекстовых файлов (изображения jpg, файлы Visio, файлы bmp, документы MS Word 2003 с изображениями и диаграммами, файлы MS Project и Подобные файлы. У меня никогда не было проблем с повреждением или чем-то подобным. И очень удобно хранить и управлять всем в SVN.

Answer 7

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

Исключением является случай, когда вы SVNing установочные образы. Мы делаем это здесь, но в другом наборе репозиториев, которые используют наши продюсеры (программисты этого не делают).

Answer 8

Я включаю все необходимые библиотеки DLL в каталог DLL в проекте и ссылаюсь на них оттуда (с копией на локальную). Затем они могут быть включены в один и тот же репозиторий / папку или перенесены с помощью svn-external из удаленного местоположения (если они используются несколькими проектами).

Answer 9

В чистой разработанной и поддерживаемой среде у вас должен быть свой собственный сервер NuGet, куда вы можете загружать свои DLL и даже сторонние DLL / двоичные файлы, ваш код должен загружать все необходимые DLL с вашего локального сервера NuGet, поэтому не фиксируйте двоичные файлы в SVN все еще держит.

Answer 10

На самом деле SVN хранит двоичные файлы намного эффективнее, чем CVS, для получения дополнительной информации см. SVN-FAQ