Использование Subversion в качестве хранилища артефактов по сравнению с конкретным инструментом управления артефактами

TL; DR: Зачем использовать что-то вроде Apache Archiva или Sonatype Nexus в качестве хранилища артефактов вместо Subversion?

Система сборки, которую я использую в настоящее время, содержит множество двоичных объектов (изображений, звуковых файлов, скомпилированных двоичных файлов и т. Д.), Как для ввода, так и для вывода в наших сборках. Наша система управления ими очень специальная; некоторые проверяются в нашем хранилище Subversion вместе с нашим кодом, некоторые хранятся в другом месте вне формального контроля версий.

Я смотрю на консолидацию этого, чтобы у нас было нечто более самосогласованное и простое в использовании, которое отделяет двоичные артефакты от кода.

Google говорит мне, что есть выбор доступных репозиториев артефактов ( Archiva , Nexus , Artifactory ,…), но, читая вокруг, я не вижу преимуществ в использовании этих по сравнению с Subversion. Это будет заботиться о двоичных файлах для нас - это уже делает это для некоторых из наших двоичных файлов, мы просто хотели бы изменить структуру хранилища, чтобы отделить их от кода - и имеет заметное преимущество в том, что у нас уже есть серверы и опыт Subversion.

Так. В чем преимущество использования выделенной системы управления артефактами по сравнению с использованием общего инструмента контроля версий, такого как Subversion?

svn dependency-management

— я и
источник

Безусловно, самым большим преимуществом использования специального инструмента является то, что другие инструменты знают, как с ним обращаться ! Они могут помещать артефакты в эти инструменты и автоматически возвращать их обратно.

— Иоахим Зауэр

см. также: programmers.stackexchange.com/questions/261751/…

— амфибия

Ответы:

Краткий ответ: как правило, вам не нужна история бинарных артефактов и изменений этих артефактов, вам просто нужны конкретные версии.

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

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

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

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

Последнее - это то, что обычно предлагается хранилищами артефактов.

Кроме того, некоторые из более профессиональных, например, Nexus, также предоставят вам информацию о лицензировании сторонних артефактов, чтобы вы не рискнули оказаться в стороне от какого-то тонкого предложения, которое вы считаете библиотекой FOSS.

— прецизионный самописец
источник

Хорошо, я должен избегать использования моего текущего хранилища Subversion в качестве хранилища артефактов, но почему бы не настроить новый хранилище Subversion? Это, кажется, имеет все те же преимущества и недостатки; хранилище артефактов, вероятно, будет иметь те же проблемы с хранением больших двоичных данных.

— me_and

@ me_and: Вы могли бы сделать это. Но тогда вам нужно решить, какая ревизия предоставляет какую версию артефакта. Зачем вам такая дополнительная работа, когда хранилище артефактов делает это за вас? Это все равно что сказать: «Итак, я мог бы использовать Блокнот для написания своего кода? Зачем тогда работать с Eclipse?» Кроме того, вы никогда не сможете по-настоящему удалить старые версии, чтобы сэкономить место. Вы можете с хранилищем артефактов.

— фунтовые

Чтобы подчеркнуть и расширить ответ @pdr, если вы будете использовать svn в качестве хранилища бинарных артефактов, вы, скорее всего, столкнетесь с проблемами хранения, поскольку svn не предназначен для удаления данных. В одном месте, где я работал, мы использовали svn для хранения артефактов, и мы регулярно превышали пределы хранения, потому что было трудно (не невозможно, но сложно) удалить старые неиспользуемые артефакты из хранилища. Собственные инструменты двоичного репозитория, такие как Artifactory и Nexus, позволяют удалять ненужные артефакты.

— Мэтью Скелтон,

Исправление: Subversion использует двоичные дельты внутри себя (а AFAIK только те). Много лет назад я проводил эксперименты с хранением файлов MS Office, и это было чрезвычайно эффективно. Размер репозитория рос очень медленно, даже при сильной перетасовке 200 слайдов PowerPoint. Но эффективность бинарного дельта-алгоритма будет сильно различаться в зависимости от типа файла, и я думаю, что проблема заключается в отсутствии политики хранения (что-то, что можно обойти с помощью отфильтрованного дампа / загрузки, но затем вы начинаете писать свое собственное решение).

— Питер Беккер

«Системы контроля версий не имеют никакого способа создания дельты» - проблема в том, что они делают именно это - с 2006 года ... subversion.apache.org/docs/release-notes/1.4.html#svndiff1 en.wikipedia. org / wiki / Xdelta

— RnR

Мы используем SVN в качестве хранилища для сборок релизов, и это очень хорошо. У нас в одном репозитории релизов лучше, чем 30 ГБ различных сборок релизов, и он хорошо выполняет сборку для развертывания.

некоторые из преимуществ этого являются ..

Двоичные файлы, добавленные в SVN, сжимаются почти на 60-70 процентов, что экономит место в среднем.
SVN служит библиотекой (артефактом) для выпусков, а хранилище резервируется для целей аварийного восстановления.
SVN через https обеспечивает безопасную доставку кода выпуска в DMZ.

— Ланс Лайонс
источник