マルチGB SVNリポジトリをGitに移動する

現在、私の会社は、次のように編成されたSVNリポジトリにVisual Studioのソリューションを持っています。

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1とTool2は独立してビルドされます（独自のソリューションがあります）が、メインビルドで使用される実行可能ファイルを生成します。ThirdPartyフォルダーには、一部のプリコンパイルされた100 MB以上の.libファイルやboostなどの大きなライブラリなど、プロジェクトのすべての依存関係が含まれています。

（1）開発者が1回のチェックアウトだけを行う必要があり、（2）ビルドの各バージョンに必要な依存関係のバージョンを追跡する必要がないように、すべてを1つのSVNリポジトリに含めると便利です。反対に、このレポを確認するには時間がかかります。

このプロジェクト構造をgitに移動する最良の方法は何でしょうか？おそらく、メインリポジトリからThirdPartyとツールを除外するのが最善ですが、ThirdPartyを1ステップで簡単にダウンロードできるようにして、バージョン管理が必要です（メインリポジトリとThirdParty / Toolsのバージョンの不一致は悪いでしょう）。

この時点では、歴史を保存することには興味がありません。そのようなプロジェクトを整理する方法を理解するだけです。

ジョブに適したツールを使用してください。Windowsでは、それはつまり

サードパーティの依存関係にNuGetを使用する

そうすれば、サードパーティの依存関係をバージョン管理された方法で維持できますが、不要なものでリポジトリを肥大化することはありません。チェックアウトははるかに高速であり、プロジェクトは必要に応じて編成されます。Visual Studioでオプションを有効にすると、常にすべての依存関係が自動的にダウンロードされます。

もちろん、git（別のリポジトリ、サブモジュールなど）を使用するだけのソリューションを使用できますが、それは単なるハックです。正しい方法でそれを行うと、すぐに成果が得られ、将来に備えたシステムが提供されます。

コメント後の編集：NuGetを使用する最良の方法は、共有ドライブまたは完全なNugetサーバーのいずれかにローカルNuGetソースをセットアップすることです。どちらの方法でも、セットアップには数分しかかかりません。そうすることで、どこから来たものであっても、必要なすべてのパッケージが常に利用可能であることを保証できます。

ツールのサブモジュールを使用できます。そうすれば、あなたは今と同じようにサブディレクトリにそれらを保持し、それらをバージョン管理するために別のレポを使用できます。また、ツールのクローンを作成（チェックアウト）して個別に開発でき、他のプロジェクトはそれらのリポジトリに依存し、特定の更新可能なバージョンにも依存する可能性があります。

サードパーティのライブラリにサブモジュールを使用することもできますが、可能な場合は、それらに依存関係マネージャを使用することをお勧めします。

gitリポジトリに変換するエンティティは、必ずバージョン管理およびブランチするエンティティです。SolutionFolder/Tools/Tool1そのようなものに対応する場合、それがエンティティのレベルです。SVNでそれを持って（良いアイデアであってもいない）ことも可能であるのに対し、Gitは、バージョン管理エンティティであることをディレクトリツリー全体の状態についてからですtrunk、branchesそしてtags、ツリー内の任意の場所を。

派生したアーティファクトをリポジトリに保存したり、外部ライブラリを保存したりしないでください。これらを処理するより良い方法があります。（Javaを使用している場合は、プライベートMavenリポジトリの使用を検討してください。比較的簡単に使用でき、他の多くのものとうまく統合できます。）

チェックアウトを容易にするためにすべてが1つのリポジトリにあるワークフローに慣れている場合は、代わりに設定を行うスクリプトを用意することを検討してください。

正直に言うと、私はあなたの設定に何も変更しません。それがまさに私たちが今していることです。私は、使用しているサードパーティのライブラリを処理するために別のgitリポジトリを設定することで遊んでいましたが、移植性のコストが重くなるとは思いません。これで、すべての開発者は、手動のセットアップ手順を実行することなく、チェックアウトして開始できます。ビルドサーバー/スレーブはプロジェクトをビルドできます。複数のリポジトリでサードパーティツールを共有している場合を除き、現在の設定をそのまま使用します。

私が遊んだのは、サードパーティのツールを別のリポジトリにセットアップすることでした。次に、1つの簡単なバッチスクリプトで、sha1 refを含むテキストファイルを読み取り、正しいバージョンをチェックアウトしました。これにより、プロジェクトごとに異なるサードパーティバージョンを使用できます。Facebook Buckビルドツールからこのアイデアを得ました。しかし、結局、多くの開発者はコマンドラインツール（MS VCショップ）を使用することを好まないため、そのアイデアをあきらめました。

（NuGetを使用して）必要なときにサードパーティのライブラリをダウンロードしない主な理由の1つは、製品を長期間サポートする必要がある場合です。私の業界では、古いサードパーティのライブラリに依存する古いバージョンのアップデートをいつか提供する必要があります。アップグレードできるライブラリを選別するのに多くの時間を費やしたくはなく、そのバージョンで使用されているライブラリを使用するだけです。今、NuGetを使用していると想像してください。必要なlibの最新バージョンは3.98ですが、2.04が必要です。彼は小さな変更を期待していたときに最新のライブラリを使用する！