Обработка зависимостей в SVN

Question

Я работаю с командой, которая скоро будет кодировать кучу Java-приложений в рамках более крупного проекта. Мы планируем использовать SVN для нашего исходного кода, но у нас будут зависимости от ряда других команд, которые НЕ используют SVN. В основном они будут кодировать несколько библиотек (в форме .jar), которые мы будем использовать в наших приложениях.

Я понимаю, что мы могли бы использовать svn: externals, если бы все были в SVN, но это не представляется возможным в ближайшем будущем. Сейчас мы, вероятно, будем просто получать обновленные файлы .jar примерно раз в неделю.

Я все еще относительно новичок в SVN, так какова правильная процедура для этого? Мы проверяем их .jar в нашем хранилище? Или мы должны избегать таких двоичных файлов в SCM? Мы также исследовали использование управления зависимостями через Maven ... который кажется хорошим вариантом для совместного использования двоичных файлов между командами, но я не уверен, действительно ли мы хотим чего-то такого сложного.

Answer 1

Я обнаружил, что управление зависимостями лучше всего выполнять с помощью репозитория maven или ivy.Artifactory и Nexus имеют бесплатные версии.Затем вы можете управлять ими из вашего скрипта сборки. Ivy , если вы используете Ant, Maven или Gradle .Я предпочитаю Gradle.

Answer 2

Предлагаю прочитать о филиалах поставщиков: http://svnbook.red -bean.com / ru / 1.5 / svn.advanced.vendorbr.html

Answer 3

Проверка в библиотеках, особенно сторонних (в вашем случае, я думаю, вы можете назвать их сторонними), в SVN (или любой SCM) не имеет большого значения, и вы получаете очень большую выгоду от этой простоты. Будьте осторожны: если банки или библиотеки слишком велики и часто меняются, вы можете пойти на более сложные задачи (например, Maven, Ivy и т. Д.)

И SVN хорош в обработке бинарных файлов и их различий.

Answer 4

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

Если они не слишком велики, то это не имеет большого значенияпроверить их в репо.

Answer 5

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