ソースコントロールに非常に大きなサードパーティライブラリ（Boost）をコミットしました。私はそれ自身のリポジトリで設定しました。私は他のプロジェクトがsvnできるように、そのバージョンにタグを付けました：この特定のバージョンを示します。サードパーティのライブラリを継続的インテグレーションの使用でソースコントロールに保存する
これは、コードをチェックインするたびにContinuous Integration（CI）サーバーが完全なチェックアウトを実行するまで、これは問題ありません。 （明らかに、私は意図的に最初のようにCIサーバーを設定しています）。これにより、CIサーバーの終了時に非常に長いチェックアウト時間が発生する可能性があります。
質問は次のとおりです。これは良いことですか？潜在的にこのパターンを処理するためのより良い方法を提案することはできますか？
EDIT：私はTeamCity CIサーバーを使用しています。
いくつかの可能性が頭に浮かぶ：
TeamCityは、デフォルトで、エクスポートされたソースをキャッシュするように構成されています（チェックアウトモード：サーバー上で自動的に）。つまり、最初のビルドには時間がかかることがありますが、その後のビルドは変更されたファイルだけをロードするため、大幅に高速になります。自動クリーンチェックアウトは特定の状況でのみ発生します。
ドキュメンテーションとソースを含むサードパーティライブラリ全体をチェックインした場合、不要なファイルを除外するチェックアウトルールを作成して、ソリューションをコンパイルするために必要なバイナリのみが残るようにすることができますコンパイルされたバイナリをチェックインしたと仮定します）。
TeamCityでは、各ビルド設定で複数のVCSルーツが許可されているため、メインのVCSルート（デフォルト）の外部を除外して、別のリポジトリにポイントされた別のVCSルートをチェックアウトBoostプリコンパイルされたライブラリを予想されるディレクトリに配置するルール。 ）
http://www.jetbrains.net/confluence/display/TCD4/Clean+Checkout#CleanCheckout-sourcescache http://www.jetbrains.net/confluence/display/TCD4/VCS+Checkout+Rules
が、私は1を考える良いアイデアのように聞こえる：
クリーンチェックアウトとチェックアウトのルールの詳細については、を参照してください。おそらく、変更されたファイルに対して単にsvn：updateを実行し、完全なチェックアウトの代わりにユニット・テストを再構築しようとすると、CIサーバーを構成する方が良いかもしれません。 – sivabudh
）をシンボリックリンクといいます.3DパーティのライブラリをCIサーバのどこかでチェックアウトし、そのディレクトリへのプロジェクトリンクを持っているだけですか？ （次回プロジェクトが再びチェックアウトされ、サードパーティライブラリには触れられていません） – sivabudh