0

サード パーティのライブラリをソース管理にコミットする場合、ビルド ステップとして解凍を行い、アーカイブとしてコミットすることがよくあります。何千ものファイルが関係している可能性があり、それらが変更されることはないと考えられているため、それらをすべて個別に保存するのは多くのオーバーヘッドのように思えます.

残念ながら、このアプローチでは、開発者がフル ビルドを実行するときに解凍が行われるまで待たなければならないなど、頭痛の種になることがあります。依存関係のチェック (解凍が必要かどうかを確認する) が、何らかの理由で確実に機能しないことがあります。

多数のファイル (現在アップグレードしている 1 つのライブラリの場合、数万) を Subversion リポジトリに追加することに欠点があるかどうかについて、オンラインで言及されているものを見つけることができません。より多くのスペースを占有すること (250 MB 未満に対して 1 GB 以上) 以外に、ライブラリ全体を個別のファイルとしてコミットすることをためらう必要があることを人々が知っている理由はありますか?

4

1 に答える 1

2

これは Java ですか、C ですか、それともどのタイプの開発ですか?

どちらの方法でも、Artifactoryを使用して、ソース管理の代わりにサード パーティのライブラリを保存できます。Java の場合は、Ivy で Maven または Ant を使用します。C または C++ の場合は、wget または curl を使用して Makefile 内のサード パーティ ライブラリを取得します。それらを保存するには、Maven の deploy:deploy-file を使用してリポジトリに配置します。または、Jenkins を使用している場合は、Jenkin のビルトイン機能を使用して、Maven リポジトリと対話して、その行為を行うことができます。

これにはいくつかの利点があります。

  • バージョンの番号付けをより適切に追跡できます。サードパーティのライブラリがリポジトリにチェックインされると、人々はそれがどのバージョンであったかを忘れてしまいます。たとえば、foo.soバージョン 1.2 をリポジトリにチェックインします。1年経つと、それがどのバージョンだったか覚えていません。の新しいバージョンをチェックインすることにした人もいfoo.soます。繰り返しますが、あなたは自分が持っているものを正確に失い始めます。これはコンパイルの依存関係であるため、知っておく必要があります。
  • これらが自己生成されたサード パーティの依存関係であっても (foo.so他のプロジェクトで使用されるビルド プロジェクトがある場合)、Artifactory などのリリース リポジトリに格納することをお勧めします。繰り返しますが、バージョン管理を追跡します。
  • 古いサードパーティの依存関係を簡単に削除できます。Subversion では、ファイルに対して a を実行しても、依存関係は引き続きリポジトリに保持されsvn rmます。保存には多くのディスク容量があります。
  • 古いサード パーティ ファイルが必要かどうかわからないため、古いサード パーティ ファイルがビルドに保持される依存関係の膨張について心配する必要はありません。依存関係をすべて指定する必要があるため、開発者が追跡しやすくなります。
于 2012-05-30T23:11:48.150 に答える