29

私はソース管理下にある大きなコードベースを持っています（以前はSubversionでしたが、現在はgitです）。コードをコンパイルしてテストを実行するために、サードパーティのライブラリのセットを使用します。これらのライブラリはいくつかのカテゴリに分類できますL

  • バイナリのみ
  • サードパーティのソース
  • サードパーティのソース+ローカルの変更

各ライブラリには、{Windows、Linux} X {デバッグ、リリース} X {32ビット、64ビット}構成があります。さらに、これらのライブラリは時間とともに進化し、プロジェクトのさまざまなバージョンがこれらのライブラリのさまざまなバージョン/ビルドを使用します。

私の質問は、これらのサードパーティを保存するための最良の方法は何ですか？

これが私の好みのセットです：

  1. プロジェクトソースリポジトリのサイズを小さく保つ
  2. プロジェクトソースをサードパーティと同期させて、いつでも古いバージョンをコンパイルして実行できるようにします
  3. 管理が簡単
  4. クロスプラットフォーム

私はいくつかの解決策を試し、考えましたが、どちらも満足のいくものではありませんでした。

  1. バージョン管理されたスクリプトを使用して、ライブラリのすべてのバージョンを保持する手動で管理されたftpサーバーからバイナリをフェッチします。これは機能しますが、サーバー上のディレクトリ構造を注意深く管理する必要があります。誰かがバイナリの1つを新しいビルドで上書きする可能性があるため、エラーが発生しやすくなります。
  2. SVN外部-当時、SVN外部は特定のタグを参照できませんでした。今日はgitを使っています。
  3. Gitサブモジュール-巨大になる可能性のある外部リポジトリ全体をプルします。または、ライブラリごとに個別のリポジトリを管理する必要があります。サブモジュールは特定のタグを指します。これは、一部だけが必要なときにすべての外部を取得するか、gitツリーで奇妙なファイルシステムを模倣することを意味します。

サードパーティのソースをベンダーブランチのgitに保存する必要があることは明らかですが、バイナリとヘッダーは別の話です。

4

3 に答える 3

13

私の問題の公正な解決策は、最近メインライン git にマージされたgit-subtreeです。これにより、私の要件とプラットフォームの制限との間で公平なバランスが保たれます。現在、外部用の複数のリポジトリがあり (それぞれにベンダー ブランチとローカルの変更ブランチがあります)、各プロジェクト リポジトリはこれらの外部の一部をサブフォルダーに取り込みます。物事を整理するために、外部サブフォルダー内の適切なファイル/フォルダーへのソフトリンクを含む「bin」および「lib」フォルダーを維持しています。

git-subtree を使用すると、サブツリーを外部リポジトリからサブフォルダーにマージできます。サブフォルダーは、外部リポジトリと前後にマージできます。

長所短所：

  1. 小さなリポジトリ - リポジトリは私が望むほど小さくはありませんが、外部リポジトリから必要な部分だけが含まれています。スペースを節約するために、外部ツリーを小さく保つようにしています。シンプルさと堅牢性を手に入れた見返りに、それは良い代償だと思います。プロジェクトの読み込みと更新は単純な git pull であり、すべてのプロジェクト関連データは単一のリポジトリに含まれているため

  2. プロジェクト/外部の同期 - プロジェクトと外部は同じリポジトリでバージョン管理されるため、必要なブランチ/タグをチェックアウトして、それが機能することを期待できます。

  3. シンプルさ - 日々の作業は簡単です。外部リポジトリの更新、新しいリポジトリの作成、または外部の別のバージョンへの切り替えは、扱いにくい場合があり、特別な構文が必要です。ただし、これは多すぎます。最良の方法は、最初にこのプロジェクトに新しい外部を追加し、後でそれを (git-subtree を使用して) 独自のリポジトリに分割できることです。

  4. クロスプラットフォーム - それは git です

  5. バイナリ - バイナリを保持するのを避け、代わりに Makefile を提供することにしました。私のエクスターナルのいくつかは他のエクスターナルに依存しているため、あまり頻繁に変更されないバイナリを構築することが非常に難しくなるため、この決定に至りました。一部の外部では、ビルド時間が非常に長いため、バイナリを保存します。

構造：

/root
   /External
      /External1 (git-subtree from git@git.domain.com:External1 v1.0)
      /External2 (git-subtree from git@git.domain.com:External2 v0.7)
   /lib
      /libExternal1.a -> ../External/External1/libExternal1.a
      /libExternal2.a -> ../External/External1/libExternal2.a
   /include
      /External1 -> ../External/External1/include
      /External2 -> ../External/External2/include
于 2012-07-13T07:36:49.963 に答える
0

オプション 3 のバリアントを選択しました。オプション 1 はオプション 3 と同等のように思えますが、実装/テストの労力が増えるため、問題が発生する可能性が高くなります。

最終的に、ビルドを正確に再作成できるようにする場合は、外部 (バイナリを含む) をコード自体と共にバージョン管理し、ローカルでホストする必要があります。そして、git サブモジュールがこれをうまくやってくれます。

于 2012-07-03T20:38:13.630 に答える
0

サードパーティのソースについては、サブモジュールがまさに探しているものだと思います。すべてのクローンでアップストリーム履歴全体を必要としない場合は、必要な履歴だけを持つ手作りのブランチを含む独自のアップストリーム リポジトリをフロントエンドします。git commit-tree作り方はこちらをご覧ください、簡単です。コミット ID は信頼できるアップストリームと一致しませんが、ツリー ID は一致します。

バイナリの場合、git annex は、git のソース差分フォーカスにうまく適合しないコンテンツを格納するための最も推奨される方法のようです。私自身は使用していませんが、デザインは本番環境での使用に適しているように見えます。また、複数の独立した `リポジトリもサポートしており、合理的に可能な限り便利に見えます。

これはターンキーではないため、実際には 3 つ目とは言えませんが、残りの作業は完了しており、必要なのは基本的なツールを簡単に使用することです。

于 2012-07-07T19:41:47.857 に答える