いくつかのライブラリとアプリケーションからなるリポジトリを構成する方法

Question

GitまたはSubversionを使用して既存のコードリポジトリを再構築/再作成する作業を成功させました。この特殊なケースでは、リポジトリ履歴は必ずしも重要ではありません。状況を分析した後、私は良いレイアウトを決定するいくつかの問題を見つけました。私は多くのブログやスレッドを読んだことがありますが、私はまだ最良のレイアウトが何であるかについてはまだ分かりません。

既存のリポジトリには、インクルードファイルのセットと、部分的に依存するライブラリセットが含まれており、その多くはインクルードファイルのセットに依存します。さらに、ライブラリのセットに依存する2つのアプリケーションプロジェクトがあります。さらに、アプリケーションの1つと追加の構成情報を使用する一連のスクリプトがあります。

が

+---------->include files 
    |    ^
    |    | 
library A -----> library B <----- library C <----- library D 
^^        |    ^
    | |        |    | 
    | +--------------------------------+    | 
    |             | 
application 1  application 2 --------------------+ 
^
    | 
script -----> configuration information 

目標は、各コンポーネントはとして独立して可能な限り開発することができ、レイアウトを持つこと、そして（外部顧客向け）のリリースを持つことであるセットが含まれています。私は状況を明確にするために、グラフを描画しました定義されたタグバージョンのすべてのコンポーネントを削除することができます。これにより、特定のリリース用のソフトウェアを適時に作成してビルドすることができます。

私は次のような構造を作ってみた：

trunk/ 
    include/ 
    lib/ 
    library A/ 
    library B/ 
    library C/ 
    library D/ 
    app/ 
    application 1/ 
    application 2/ 
tags/ 
    1.0/ 
    include/ 
    lib/ 
     library A/ 
     library B/ 
     library C/ 
     library D/ 
    app/ 
     application 1/ 
     application 2/ 
    1.1/ 
    include/ 
    lib/ 
     library A/ 
     library B/ 
     library C/ 
     library D/ 
    app/ 
     application 1/ 
     application 2/ 
    ... 

たびに私は、私は単に、タグに新しいサブディレクトリにリポジトリ全体をコピーする新しいリリースを作成します。

このソリューションの問題点は、ライブラリにタグディレクトリが別に存在しないこと、タグ付きコンポーネントで構成されるリリースのみを使用したいということです。このソリューションでは、どのコンポーネントにどのタグバージョンリリース。私は別のリポジトリを使うことを考えていましたが、 `svn：externals 'と特定のタグのサブディレクトリを使って必要なコンポーネントをリンクするリリースのサブディレクトリを持つマスターリポジトリを作成しましたが、コードを別のエンティティに分割する方法を理解していません。

アイデア？

===============質問は、28-1-2011 =============== [OK]を

に続きます新しいレイアウトをどのように計画するかのグラフを描きました。目標はさまざまな依存関係の タグを1つの リポジトリ内のsvn：externalsメソッドとリンクすることです。例えば、^/tags/projects/includeの trunk/projects/lib/library2/dependenciesにsvn：externalsを設定します/std/1.3。

trunk/ 
    projects/ 
    include/ 
     std/ 
    lib/ 
     library1/ 
     dependencies/ 
      std/ --> tags/projects/include/std/1.2 
     library2/ 
     dependencies/ 
      std/ --> tags/projects/include/std/1.2 
      library1/ --> tags/projects/lib/library1/1.4.3 
     library3/ 
     dependencies/ 
      std/ --> tags/projects/include/std/1.3 
      library1/ --> tags/projects/lib/library1/1.4 
    app/ 
     application1/ 
     dependencies/ 
      library3/ --> tags/projects/lib/library3/1.1 
     application2/ 
     dependencies/ 
      library1/ --> tags/projects/lib/library1/2.1 
     application3/ 
     dependencies/ 
      std/ --> tags/projects/include/std/1.2 
      library2/ --> tags/projects/lib/library2/1.5.2 
    config/ 
     configuration1/ 
     dependencies/ 
      application1/ --> tags/projects/app/application1/2.3 
     configuration2/ 
     dependencies/ 
      application1/ --> tags/projects/app/application1/1.6 
     configuration2/ 
     dependencies/ 
      application2/ --> tags/projects/app/application1/1.6 
tags/ 
    projects/ 
    include/ 
     std/ 
     1.2/ 
     1.3/ 
    lib/ 
     library1/ 
     1.4.3/ 
     1.4/ 
     2.1/ 
     library2/ 
     1.5.2/ 
     library3/ 
     1.1/ 
    app/ 
     application1/ 
     1.6/ 
     2.3/ 
branches/ 
    ... 

残りの質問：

• は、この設計実行可能です、またはあなたはすべての主要な欠点を見ていますか？
• ライブラリをタグディレクトリにコピーするとどうなりますか？これにより、 svn：externalsプロパティもコピーされます。これは問題を引き起こすか、またはこの動作が望まれますか？
• すべての外部に対して明示的なリビジョンを指定できますが、タグは変更しないでください。ディレクトリで十分ではありませんか？
• リポジトリを開発リポジトリとsvn：externalを使用するリポジトリに分割する方がよいでしょうか？質問What's the benefits of "svn:externals"?の回答「ユースケース」を参照してください。

Answer 1

タクソノミーを内側に向けることをお勧めします。この構造ができるようになりますのgitで

companyname/ 
    include/ 
    trunk/ 
    tags/ 
    branches/ 
    libraryA/ 
    trunk/ 
    tags/ 
    branches/ 
    libraryB/ 
    trunk/ 
    tags/ 
    branches/ 
    libraryC 
    trunk/ 
    tags/ 
    branches/ 
    libraryD/ 
    trunk/ 
    tags/ 
    branches/ 
    application1 
    trunk/ 
    tags/ 
    branches/ 
    application2 
    trunk/ 
    tags/ 
    branches/ 

、私はあなたには、libraryA、libraryB、アプリケーション1、などのために別々のGitのリポジトリを作成する必要があります示唆...

：Subversionでは、私はこのような分類法を提案します異なるパーツ間であらゆる種類の依存関係を作成することができます（たとえば、application1のブランチは、libraryAプロジェクトの不安定バージョンに依存しますが、application1のHEADはlibraryAプロジェクトの安定版に依存する可能性があります）。

この構造はまた、ほとんどがなど

それはあなたのアプリケーションのデプロイされたバージョンのための良好な構造だが、良いではないようにあなたのルックスを提示分類のmaven、熊手、buildr、アリ、のようなツールを構築するだけでなくで動作しますバージョン管理のための構造。経験から、私がバージョン管理のために提案したような構造を使用し、ビルドスクリプト（またはビルドツール）を使用して、あなたのアプリを出荷する。

UPDATE：作業サイクルが行くかもしれない方法で少し詳しく説明するには、次の

ので、例えば、我々は（のは、このバージョン1.0.0を呼びましょう）アプリケーション1のためのバグ修正を実装し終えたとしましょう。最新の大きな変更はapplication1/trunkにチェックインされます。このバージョンのApplication1は、libraryD v0.5.0に依存します。 application1/trunk/README.txtを、このバージョンがlibraryD v0.5.0に依存していることに注意して更新します。おそらくもっと重要なのは、application/trunk内のビルドスクリプトがlibraryD/tags/0.5.0をチェックアウトする方法を知っていることでしょう。次に、application1/tags/1.0.0にタグ（現在の状態のトランクのコピー）を作成します。

ここで、1週間が経過し、別の開発者がlibraryDをバージョン1.3.0に更新したとしましょう。あなたはapplication1を強化する必要があります。したがって、application1/trunkを変更してください。次に、application1/trunk/README.txtを更新して、libraryD v1.3.0に依存していると言います（同様に、application1 v1.3.0の新しいビルドスクリプトはcheckout libraryD/tags/1.3.0になります）。 application1/trunkをapplication1/tags/1.1.0にコピーします。

これで、必要に応じていつでもapplication1/tags/1.0.0に戻すことができます（libraryD/tags/0.5.0からコードを取得することができます）。application/tags/1.1.0はlibraryDバージョン1.3を使用します。 0

subversionとgitの両方で、タグは特定の時点のファイルセットを参照するためのものです。つまり、タグはあまりスペースを取らないので、タグを早く、頻繁に言う。 - ）

Answer 2

重要な質問は、すべてのライブラリとアプリケーションが単一の製品に緊密に結合されているか、または互いに独立して生きることができるかどうかです。 IMOそれらを単一のgitリポジトリに入れることは意味があります。すべてのlibsとappsが単一の製品であれば、svn以外ではgitツリーの一部しかチェックアウトできません。 libsとappsが独立している場合は、各lib/appのリポジトリを作成し、それらをサブモジュールを介して接着することができます。

gitサブモジュールはsvn extarnalsと似ていますが、常にターゲットの特定のリビジョンを参照します。プレーンなURLではありません。したがって、git checkout deadbeefを実行すると、deadbeefがコミットされた時点から、参照されたリポジトリの先頭に関係なく、サブモジュールの状態が常に取得されます。したがって、gitタグは、リビジョン固定URLでないsvnとは異なり、各サブモジュールの状態を取ります。