Регистрируясь в файлах БАНКИ (библиотеки) в инструмент Контроля Вариантов - действительно ли это - хорошая практика?

Я бы порекомендовал, чтобы по возможности, вы должны использовать Maven . Тогда вам не нужно было бы проверить сторонние банки в ваш репозиторий, чтобы поделиться с ними среди вашей команды развития (большую часть времени).

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

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

Я думаю, что это все еще актуально, но SVN исторически проводил плохо с двоичными дворами. Разработчик Java в IBM столкнулся с этим вопросом, исследовал и записал свои выводы. Возможно, вы можете найти это полезным:

Subversion Performance Tuning Subversion: хранить и обрабатывать двоичные файлы без перетаскивания производительности

Вот на вынос:

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

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

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

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

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

В-третьих, как управлять межпроектными зависимостями (где один из ваших проектов зависит от другого)? Проверяется ли jar-файл из одного в другой? Как насчет версионирования и другого управления изменениями? Нужно просто проверить два проекта и потребовать, чтобы они были собраны в строгом порядке?

По моему опыту и по моему мнению, этих проблем обычно достаточно в разработке только умеренной сложности, чтобы ответить на вопрос окончательно: Нет, недопустимо проверять в jar-файлах зависимости. Используйте систему сборки, такую как Maven или Ant+Ivy (или другую альтернативу), которая обеспечивает способ экстернализации управления и хранения зависимостей от системы управления исходным кодом.