フレームワークランタイムをソース管理下に保存することは良い習慣ですか？

多くのソフトウェアショップがバイナリをソース管理下に置いていることを知っています。しかし、私たちのショップは、DirectXランタイム、CUDA、nVidia Optixなど、フレームワーク全体をリポジトリに格納するようになりました。

開発マシンのセットアップをより簡単にすると言われています（おそらく最新のものを入手してコーディングを開始します）。ただし、リポジトリが大幅に肥大化し、無関係な履歴が発生します。

このような使用パターンを見たことがありません。それは良い習慣だと思いますか？

[編集：]分離されたサードパーティのバイナリをソース管理することに問題はありません。質問は、通常10以上のバイナリで構成されるフレームワークランタイム全体に関係しています。極端な例として、Windows SDKを取り上げます（これはリポジトリに保持しません。感謝しますが、原則として違いはありません）。

以下の理由により、バイナリは通常、バージョン管理システムにはあまり適していません。

• バージョン管理機能（マージ、差分）の恩恵を受けない
• 彼らはリポジトリのサイズを増やします...
• ...重要なのは、単純な共有ディレクトリであるNexusのようなアーティファクトリポジトリ（クリーンアップが簡単：+ ！）とは対照的に、VCSからバージョンを簡単に削除しないためです（VCSは履歴を保持するために作成されます）。cdrm
• それらはVCSでテキスト、パス+バージョンの宣言として参照する必要があります。関連する履歴をそのように保持し、バイナリバージョンの変更をそのテキストファイルの変更として記録できます（Nexusを使用している場合はpom.xmlなど）例えば）

バイナリアセットのバージョン管理で問題ありません。生成されたファイルのバージョン管理には反対です。

また、環境設定は開発とは異なります。私たちは主にPythonで開発しており、virtualenvと呼ばれるツールを使用して、プロジェクトの軽量の隔離された環境（ライブラリを含む）を作成できます。ソースをチェックアウトすると、そこにこのvirtualenvを構築するセットアップスクリプトがあります。マニフェストを使用して、必要なライブラリのバージョンなどを指定します。これはバージョン管理されていません。セットアップスクリプトのみです。

メインプロジェクトの下にフレームワーク全体を投げると、履歴が乱雑になり、深刻な混乱を招きます。これはプロジェクトの一部ではないため、別の方法で処理する必要があります。

フレームワークのバージョンで構成管理を行うことは、一般的に良い考えです。コードで特定のDirectXバージョンが必要な場合は、そのバージョンを簡単に入手でき、古いバージョンのソフトウェアをチェックアウトすると、外部の依存関係を簡単に特定できます。

ここで私が良い考えだとは思わないのは、これらのバイナリを格納するために典型的なバージョン管理システムを使用することです。当社では、フレームワーク、ライブラリ、外部ツールのすべてのバージョンをネットワークドライブのサブフォルダー構造に保存しています。私たちが理にかなっていると思う場合は、どのツールバージョンがどのソフトウェアバージョンに属しているかを文書化するreadmeファイルを用意しています。または、可能であれば、特定のバージョンをインストールまたは使用するためのスクリプトを用意しています。これらのREADMEファイルとスクリプトのみがバージョン管理に入ります。

また、ツールによっては、古いバージョンのツールとライブラリを再構築する必要がある可能性があると考える限り、古いバージョンを保持します。こうすることで、非常に古いlibs＆toolsが非推奨になったときにネットワークドライブから削除できるようになります（もちろん、外部メディアにアーカイブがある場合に備えて）。

バイナリはどこかにあるべきだと思います。特にそれらが大きく、チェックアウト時間が長くなる場合は、リポジトリの外に保管することをお勧めします。私はそれが悪い習慣であるとは思わないでしょうが、それは私が見たものではありません。

組織がさまざまなランタイムバージョンを対象とするプロジェクトを多数持っている場合、これは実際には良い考えです。これにより、適切なプロジェクトで作業しているときに、適切なランタイムバイナリを使用できます。

私は個人的にこれを非常に悪い習慣だと思っています。インストール手順を記載したWikiをセットアップし、それに必要なバイナリをアップロードすることを好みます。これらのファイルは新しい開発者のみが必要とするものであり、他のすべての人のリポジトリを膨らませる必要はありません。

これには十分な理由があります。つまり、外部の依存関係なしに、必要なすべてのものが1つの場所にあるということです。

これはあなたが思っているよりもずっと重要です。これにより、すべてが社内にあるため、ベンダーサーバーのアーティファクトに依存せず、数年後にはなくなる可能性があります。

リポジトリ膨張について。これは、クローン作成や更新が遅くなるため、VCSが完全なローカルコピーを保持している場合にのみ問題になります（gitはこれを行い、cvsはしません）。その代わりに、各開発マシンにコピーがあり、何らかの理由で中央バックアップスキームがいつか失敗した場合に会社を救うことができます。

それは優先順位または方針の問題です。決定が慎重である限り、私はこれで大丈夫でしょう。