1

以下で構成される大規模なプロジェクトがあります。

  • A: C++ ソースコード / ライブラリ
  • B: SWIG を使用した C++ ライブラリの Java および Python ラッピング
  • C: Java API/ラッピングに依存する Java で書かれた GUI。

人々は可能な限りすべての方法でプロジェクトを使用します:

  • C++ API を使用した C++ プロジェクト
  • Java API を使用した Java プロジェクト
  • Python スクリプト
  • MATLAB スクリプト (Java API を使用)
  • Java GUI 経由

現在、A、B、C はすべて単一の Subversion リポジトリにあります。git/GitHub に移行するため、再編成の機会があります。A、B、C をそれぞれのリポジトリに分割することを考えています。これにより、いくつかの疑問が生じます。

  1. Java と Python の SWIG ラッピング (つまり、インターフェース (*.i) ファイル) を別個のリポジトリーに分割することは理にかなっていますか?
  2. 現在、SWIG で生成された .java ファイルは GUI のソース ツリーに出力され、SVN で追跡されます。Git リポジトリでマシン生成ファイルを追跡したくないので、SWIG によって生成された .java/.jar ファイルに対する GUI の依存関係を維持する最善の方法は何ですか? これを考慮してください。新しい開発者が Java GUI を構築したい場合、A と B をゼロから構築する必要はありません。GUI をすぐに構築できる C のコピーを入手できるはずです。
  3. バージョン管理: すべてが 1 つのリポジトリにある場合、A、B、および C は必然的に互いに一貫性があります。異なるリポジトリがある場合、GUI は既知のバージョンのラッピングで動作する必要があり、ラッピングは既知のバージョンの C++ API で動作する必要があります。これを管理する最善の方法は何ですか?

私たちはこれらの質問のそれぞれについて深く考えてきましたが、コミュニティがこれらの問題にどのように取り組むかを聞きたいと思っています. おそらく git submodule/subtree はこれらの解決策の一部ですか? これらのいずれも使用していませんが、サブモジュールは人々に頭痛の種を引き起こしているようです. これらのいずれかで成功した例はありますか?

4

1 に答える 1

0

OK、私はあなたのような同様の問題（複数の相互作用するプロジェクト）を調べ、3つの可能性と、個々のパーツを含む複数のフォルダーを持つ単一のプレーンリポジトリを試しましsubtreeたsubmodules。より多くの/より良い解決策がある場合、私はそれらに気づいていません。

要するに、私は単一のリポジトリに行きましたが、これはあなたのケースでは最善の解決策ではないかもしれません.

  • の利点はsubmodules、すべてのパーツ自体がリポジトリであるため、管理が容易になることです。したがって、個々の関係者は自分のリポジトリでのみ作業でき、他の部分は事前定義されたバイナリ リリースから追​​加できます/... (好きなように)。個々のリポジトリを連結する追加のリポジトリを追加する必要があります。
    これは長所と短所の両方です。このリポジトリの各コミットは、実行中の構成を定義します。理想的には、開発者は各コミットを「作業リポジトリ」(A ～ C) 用と構成リポジトリ用に 2 回行う必要があります。
    したがって、この方法は、AC をほとんど独立させ、あまり頻繁に変更しないようにする場合 (これは新しいリリースの場合のみ) に適している可能性があります。
  • subtree私は個人的にその方法が好きではなかったことを告白しなければなりません. 私（個人的に）にとって、構文はぎこちなく見え、メリットはそれほど大きくありません。
    利点は、リモートの変更を簡単にフェッチして挿入できることですが、リモートの履歴が失われることです。したがって、リモート開発に干渉することは避ける必要があります。
    これはマイナス面です。パーツを変更する場合は、常に履歴を気にする必要があります。もちろん、git リモートで開発し、masterブランチへの変更をテスト/マージ/統合することもできます。これは、主にリモート リポジトリを読み取る場合 (A のみで開発していて、B と C が必要な場合) には問題ありませんが、通常の変更 (A の例) には問題ありません。
  • 最後の可能性は、各パーツのフォルダーを含む 1 つの単純なレポです。利点は、パーツの同期を維持するための管理が直接必要ないことです。ただし、各コミットが実行中のコミットになることを保証することはできません。また、開発者は手作業で管理を行う必要があります。

選択は、個々のパーツ AC がどれだけ密接に相互接続されているかに依存することがわかります。ここで私が推測できる
のは、ソース ツリー全体の変更が一般的である開発の初期段階にいる場合は、分割バージョンよりも 1 つの大きなレポの方が扱いやすいということです。インターフェースがほぼ一定の場合、分割によりリポジトリが小さくなり、物事をより厳密に分離できます。
SWIG コードと C++ コードは非常に近いようです。したがって、これら2つを分割することは、GUIを残りから分割するよりも実用的ではないようです(私の推測では)。

他の質問「新しい開発者の処理方法/機械生成コードの追跡 (非) 処理方法は?」:
作成/必要なコミットの数 (リリースのみまたは個々のコミット)? リリースのみに関心がある場合は、バイナリ パッケージを使用できます。単一のコミットを共有する場合は、多数の異なるバイナリ バージョンを提供する必要があります。ここでは、一度数分かかるツリー全体をコンパイルさせ、そこからの再構築は、makeそれほど長くはかからない短いものにすることをお勧めします。これは、フックを使用して自動化することもできます。

于 2015-08-31T07:52:02.980 に答える