1

私が一緒に働いていたチームは、svn から git に移行することに決めました。これは良いことだと思います。私は移行と現在の svn レイアウトの再構築を担当しています。

現在svnにあるものは次のようになります:

/externals  (external libs copyed there like cunit, etc.)
/include    (public headers only)
    /libA
    /libB
    /libC
/source     (source and private headers)
    /libA
    /libB
    /libC
/tests      (tests projects)
    /libA
    /libB
    /libC

git について調査したところ、モジュール式のアプローチが好まれることがわかりました。だから私はこの構造を思いついた：

/externals      (repo externals.git)
/libA           (repo libA.git)
   /include
   /source
   /tests
/libB           (repo libB.git)
    ...

ただし、この種のモジュール性と、相互に依存している場合に異なるライブラリを使用するという点が壊れていると思います( libBには libA が必要であり、libD には libA と libC が必要です)。libA を依存関係として追加するには、libB のスコープを離れる必要があります。

次に、すべてのライブラリに「依存関係」フォルダーを追加し、そこにサブモジュールとして追加する必要がありますか、それとも初期の git レイアウトを維持する必要がありますか?

ここで推奨されるアプローチは何ですか?

ありがとう

4

1 に答える 1

0

より信頼性の高いアプローチは、モジュールごとに独立したプロジェクト ライフサイクルを持つことです。また、ライブラリをリリースするときは、バージョン番号を維持する必要があります。依存関係は、どのモジュールとどのバージョンのライブラリが必要かを示す必要があります。たとえば、libB:1.0.0 には libA:1.2.5 が必要であり、libD:3.4.5 には libA:1.3.7 と libC:5.3.9 が必要です。mavenたとえば、Java の世界、debLinux ディストリビューション、nugetC#には、依存関係管理システムがあります。正確なバージョンを追跡し、バージョン番号の競合を確認できます。たとえば、libB:1.0.0 と libD:3.4.5 を必要とする myApp:6.2.5 がある場合、myApp が 2 つの異なる (潜在的に互換性のない) バージョンに依存していることを意味します。 libA の - 1.2.5 および 1.3.7。

変更されたモジュールを構築し、依存関係を再構築し、テストを実行して互換性の問題を非常に迅速に追跡する継続的統合サーバーを使用できる場合。

つまり、バージョン依存関係の管理は、git や svn などのバージョン管理システムのタスクではなく、特別なツールを使用する方が適切です。ただし、git サブモジュールまたは svn-externals を使用して処理できますが、うまく機能しません。

于 2013-04-03T14:44:11.230 に答える