アーティファクトリポジトリとしてのSubversionと特定のアーティファクト管理ツールの使用

TL; DR：Subversionではなく、Apache ArchivaやSonatype Nexusなどをアーティファクトリポジトリとして使用する理由は何ですか？

現在使用しているビルドシステムには、ビルドへの入力と出力の両方として、多くのバイナリブロブ（イメージ、サウンドファイル、コンパイル済みバイナリなど）があります。これらを管理するシステムは非常にアドホックです。コードとともにSubversionリポジトリにチェックインされるものもあれば、正式なバージョン管理外の別の場所に保存されるものもあります。

私はこれを統合しようとしているので、より一貫性があり使いやすいものがあり、コードからバイナリアーティファクトを分離します。

Googleは、利用可能なアーティファクトリポジトリ（Archiva、Nexus、Artifactory、…）の選択があると言っていますが、読み返してみると、これらをSubversionよりも使用する利点はありません。それは私たちのためにバイナリの世話をします-それはすでにいくつかのバイナリのためにそれを行います、私たちはそれらをコードから分離するためにリポジトリレイアウトを再配置したいだけです-そして、すでにSubversionサーバーと専門知識を持っているという顕著な利点があります。

そう。Subversionのような一般的なバージョン管理ツールを使用するよりも、専用のアーティファクト管理システムを使用する利点は何ですか？

簡単な答え：一般に、バイナリアーティファクトの履歴とそれらのアーティファクトの変更は必要ありません。特定のバージョンが必要なだけです。

長い答え：バイナリファイルに小さな変更をコミットするたびに、バージョン管理システムにはデルタ（2つのファイル間の差分）を作成する方法がないため、まったく新しいコピーが作成されます。

SVNのようなCVCSでは、リポジトリの中央コピーが1つしかないため、それほど苦痛はありません。ローカルコピーは1つのバージョンにすぎません。（それでも、リポジトリは非常に大きくなり、チェックインが遅くなる可能性があります。）しかし、後でリポジトリのすべてのコピーがすべてのファイルの完全な履歴を持つDVCSに切り替えるとどうなりますか？そこでは、変更のサイズが非常に重要になります。

そして、それは痛みの見返りにあなたに何を与えますか？提供されるのは、リポジトリの以前のバージョンに戻って、そのバージョンの正しいバイナリがあることを知ることができるということだけです。

しかし、それを行うにはリポジトリにバイナリ全体が必要ですか？または、単にテキストファイルを用意して、他のリポジトリから他の場所から取得するバージョンをビルドプロセスに伝えるだけで済みますか？

後者は、一般にアーティファクトリポジトリによって提供されるものです。

さらに、Nexusなどのよりプロフェッショナルなものの一部は、サードパーティのアーティファクトのライセンスに関する情報も提供するため、FOSSライブラリと思われる微妙な条項に違反するリスクがありません。

SVNはリリースビルドのリポジトリとして使用され、非常にうまく機能します。1つのリリースリポジトリには、さまざまなリリースビルドの30GBよりも優れており、デプロイ用にビルドを適切に引き出します。

これを行う利点のいくつかは..

• SVNに追加されたバイナリは、平均節約スペースで60〜70％近く圧縮されます。
• SVNはリリースのライブラリ（工房）として機能し、リポジトリは災害復旧の目的でバックアップされます。
• httpsを介したSVNにより、DMZにリリースコードを安全に配信できます。