ソース管理でのサードパーティライブラリの保存

アプリケーションが依存するライブラリをソース管理に保存する必要がありますか？私の一部はそうすべきだと言い、別の部分はそうではないと言います。アプリのいくつかの関数に依存しているという理由だけで、アプリ全体を小さくする20 MBのライブラリを追加するのは間違っていると感じます（かなり重くはありますが）。jar / dllを保存する必要がありますか、それともプロジェクトの分散zip / tarを保存する必要がありますか？

他の人は何をしますか？

リポジトリにサードパーティのライブラリがあるだけでなく、ライブラリの将来の更新（セキュリティの修正など）を簡単に追跡してマージできるようにすることも価値があります。適切なベンダーブランチを使用してSubversionを使用している場合は、価値があります。

サードパーティのコードを変更する前に地獄の寒い日になることがわかっている場合は、（@ Matt Sheppardが言ったように）外部が理にかなっており、に切り替えるのが非常に簡単になるという追加の利点がありますライブラリの最新バージョンは、セキュリティアップデートまたは必須の新機能によってそれが望ましいものになるはずです。

また、コードベースを更新するときに外部をスキップして、必要に応じて長い低速ロードプロセスを節約できます。

@Stu Thompsonは、ドキュメントなどをソース管理に保存することに言及しています。大規模なプロジェクトでは、請求書/請求書/議事録/技術仕様などを含む「clients」フォルダ全体をソース管理に保存しました。撮影の試合全体。ただし、これらは、次のユーザーが利用できるようにするリポジトリとは別のリポジトリに保存することを忘れないでください。他の開発者。クライアント; あなたの「ブラウザソースビュー」...咳... :)

10年後にプロジェクトを構築するために必要なすべてのものを保存します。万が一の場合に備えて、ライブラリのzipディストリビューション全体を保存します。

2017年の編集：この回答は古くなりませんでした:-)。antやmakeなどの古いものをまだ使用している場合は、上記が引き続き適用されます。依存関係管理でmavenやgraddle（または.net上のNuget）などのより新しいものを使用する場合は、バージョン管理サーバーに加えて、依存関係管理サーバーを実行する必要があります。両方の適切なバックアップがあり、依存関係管理サーバーが古い依存関係を削除しない限り、問題はありません。依存関係の管理サーバの例については、例えば参照SonatypeネクサスまたはJFrog Artifcatory他の多くの間で、。

ライブラリを保存しないでください。それらは厳密に言えばプロジェクトの一部ではなく、リビジョン管理システムのスペースを無駄に占有します。ただし、プロジェクトで使用されている外部ライブラリのバージョンを追跡するには、maven（またはantビルドの場合はIvy）を使用してください。組織内で（バックアップされている）リポジトリのミラーを実行して、依存関係を常に管理できるようにする必要があります。これにより、両方の長所が得られるはずです。プロジェクト外の外部jarですが、確実に利用でき、一元的にアクセスできます。

ソースコードをチェックアウトしてビルドスクリプトを実行するだけでプロジェクトをビルドできるようにするため、ライブラリをソース管理に保存します。最新のものを入手して1つのステップでビルドできない場合は、後で問題が発生するだけです。

サードパーティのバイナリをソース管理に保存しないでください。ソース管理システムは、同時ファイル共有、並列作業、マージ作業、および変更履歴をサポートするプラットフォームです。ソース管理はバイナリ用のFTPサイトではありません。サードパーティのアセンブリはソースコードではありません。SDLCごとに2回変更される可能性があります。ワークスペースをクリーンにワイプし、ソース管理からすべてをプルダウンしてビルドできるようにしたいという願望は、サードパーティのアセンブリをソース管理に留める必要があるという意味ではありません。ビルドスクリプトを使用して、配布サーバーからのサードパーティアセンブリのプルを制御できます。アプリケーションのどのブランチ/バージョンが特定のサードパーティコンポーネントを使用するかを制御することを心配している場合は、ビルドスクリプトを介してそれを制御することもできます。人々はMavenfor Javaについて言及しており、MSBuild for.Netでも同様のことができます。

私は通常それらをリポジトリに保存しますが、サイズを小さくしたいというあなたの願望に共感します。

それらをリポジトリに保存しない場合は、どういうわけかアーカイブしてバージョン管理する必要があり、ビルドシステムはそれらを取得する方法を知っている必要があります。Javaの世界の多くの人々は、依存関係を自動的にフェッチするためにMavenを使用しているようですが、私はIを使用したことがないので、賛成または反対することはできません。

1つの良いオプションは、サードパーティシステムの個別のリポジトリを保持することです。Subversionを使用している場合は、Subversionの外部サポートを使用して、他のリポジトリからライブラリを自動的にチェックアウトできます。それ以外の場合は、ビルドシステムが要件を自動的にフェッチできる内部匿名FTP（または同様の）サーバーを維持することをお勧めします。もちろん、古いバージョンのライブラリをすべて保持し、リポジトリとともにすべてをバックアップしておく必要があります。

私が持っているのは、すべてのサードパーティライブラリ（ライブラリだけでなく、ドキュメント、Javadoc、その他すべてを含むそれぞれのソースディストリビューション）が格納されているイントラネットのMavenのようなリポジトリです。その理由は次のとおりです。

1. 変更されないファイルを、変更されるファイルを管理するために特別に設計されたシステムに保存するのはなぜですか？
2. それは劇的にチェックアウトを固定します
3. ソース管理下に保存されている「something.jar」を見るたびに、「それはどのバージョンですか？」と尋ねます。

JDKとIDE以外のすべてをソース管理に入れました。

トニーの哲学は健全です。データベース作成スクリプトとデータ構造更新スクリプトを忘れないでください。ウィキが出る前は、ドキュメントをソース管理に保存することさえありました。

私の好みは、サードパーティのライブラリをSubversionに保持するのではなく、依存関係リポジトリ（Artifactory with Mavenなど）に格納することです。

サードパーティのライブラリはソースコードのように管理またはバージョン管理されていないため、それらを混在させることはあまり意味がありません。また、リモート開発者は、任意の数の公開リポジトリからより簡単にライブラリを取得できる場合、低速のWPNリンクを介して大きなライブラリをダウンロードする必要がないことを高く評価しています。

以前の雇用主では、アプリケーションをソース管理で構築するために必要なすべてのものを保存していました。新しいビルドマシンの起動は、ソース管理と同期し、必要なソフトウェアをインストールすることでした。

サードパーティのライブラリをソース管理に保存して、コードを新しい開発環境にチェックアウトしたときに利用できるようにします。ビルドスクリプトに含まれる可能性のある「インクルード」またはビルドコマンドも、これらの「ローカル」コピーを参照する必要があります。

依存しているサードパーティのコードまたはライブラリを常に利用できるようにするだけでなく、新しい開発者がチームに参加したときに、コードを新しいPCまたはユーザーアカウントで（ほぼ）構築する準備ができていることも意味します。

ライブラリを保存してください！リポジトリは、いつでもプロジェクトを構築するために必要なもののスナップショットである必要があります。プロジェクトには異なるバージョンの外部ライブラリが必要なため、これらのライブラリの新しいバージョンを更新/チェックインする必要があります。そうすれば、古いリリースなどにパッチを適用する必要がある場合に、古いスナップショットに対応するすべての適切なバージョンを取得できます。

個人的には、プロジェクトの一部としてdependanciesフォルダーがあり、そこに参照ライブラリを格納しています。

多くの場合、同じバージョンのライブラリを必要とする相互依存する部分があるため、特定のライブラリの最新バージョンに更新できるとは限らないため、さまざまなプロジェクトで作業するので、これにより作業が楽になります。

各プロジェクトのコンパイル時にすべての依存関係が使用されるということは、物事が進んだ数年後でも、他の部分を壊すことを心配することなく、プロジェクトの任意の部分を構築できることを意味します。ライブラリの新しいバージョンへのアップグレードは、ファイルを置き換えて関連コンポーネントを再構築するだけのケースであり、必要に応じて管理するのはそれほど難しくありません。

そうは言っても、私が参照しているライブラリのほとんどは、数百kb程度の比較的小さいものであり、それより大きくなることはめったにないため、ソース管理に固定するだけの問題は少なくなります。

gitサブプロジェクトを使用し、サードパーティライブラリのメインgitリポジトリから参照するか、（存在しない場合は）必要なライブラリごとに新しいgitリポジトリを作成します。gitリポジトリが1つだけに制限されている理由は何もありません。また、他の誰かのプロジェクトを自分のディレクトリとして使用することはお勧めしません。

プロジェクトのビルドに必要なものをすべて保存して、何もせずにチェックアウトしてビルドできるようにします。

（そして、苦痛を経験した人として-コントロールをインストールして開発プラットフォームで動作させるために必要なすべてのコピーを保管してください。私はかつてビルドできるプロジェクトを手に入れました-しかし、インストールファイルとregキーがなければできませんでしたサードパーティのコントロールレイアウトに変更を加えないでください。それは楽しい書き直しでした）

プロジェクトをビルドするために必要なものをすべて保存する必要があります。さらに、コードのバージョンが異なれば、サードパーティへの依存関係も異なる可能性があります。コードをサードパーティの依存関係とともにメンテナンスバージョンに分岐する必要があります...

個人的に私が行ってこれまでの結果が気に入ったのは、ライブラリを個別のリポジトリに保存し、Subversion svn：externals機能を使用して他のリポジトリで必要な各ライブラリにリンクすることです。ほとんどのライブラリ（主に管理されている.NETアセンブリ）のバージョン管理されたコピーを、メインのソースコードリポジトリのサイズをまったく大きくすることなくソース管理に保持できるため、これはうまく機能します。この方法でアセンブリをリポジトリに保存すると、ビルドサーバーでビルドを作成するためにアセンブリをインストールする必要がなくなります。Visual Studioがインストールされていない状態でビルドを成功させるのは非常に面倒でしたが、動作するようになったので、満足しています。

現在、商用のサードパーティのコントロールスイートなどをあまり使用していないため、ビルドサーバーに実際にSDKをインストールする必要があるライセンスの問題は発生していませんが、どこにあるかはわかります。簡単に問題になる可能性があります。残念ながら、私にはその解決策がなく、最初に遭遇したときに対処する予定です。