ネストされたバージョン管理体系ですか？

Question

いくつかのバージョンコントロール（gitまたはsvn、好ましくは）でこのプロジェクト構造を最もよく追跡する方法に関する提案を探しています：

このプロジェクトは、複数のバージョンの「コア」コードを持つWebサービス用です。ユーザーはWebサービスのインスタンスを（使用可能なバージョンの）「コア」のいずれかで作成できます。このようにして、開発/ベータ版は安定版と同じサーバー上に存在します。

したがって、複数の「コア」が存在し、バージョンコントロールで異なるリリース/タグ/ブランチになる可能性があります。しかし、これらのWebファイルのために独自の追加のバージョン管理プロジェクトが必要なWebインターフェイスがあります。

構造の観点から、それは次のようになります。2.0-betaは別の開発である一方、そう

/-+ 
    | 
    +--index.php 
    +--engine/ 
    | | 
    | +--1.0-stable/ 
    | | | 
    | | +--feature.php 
    | +--2.0-beta/ 
    |  | 
    |  +--feature.php 
    +--main.css 
    +--main.js 

、index.php、main.cssとmain.jsは、Webインターフェイスで、独自の「プロジェクト」の一部でありますブランチの更新は最終的に2.0-stableブランチにマージされ、1.0ブランチのfeature.phpへの修正は2.0 feature.phpファイルにマージする必要があります。

reposの中にreposを作成できますか？これはどのようにして最高に管理されますか？

Answer 1

ディレクトリ構造がそのように見える必要がない場合は、エンジン用とインフラストラクチャ用の2つのリポジトリがあります。エンジンレポには2つ（またはそれ以上）のブランチがあり、これらのブランチのそれぞれはインフラストラクチャリポジトリをサブモジュール（gitの場合はsvn：externals、SVNの場合は）にします。

こうすれば、エンジンのブランチで正常に動作することができますが、インフラストラクチャの変更は共有されます。もちろん、必要が生じた場合は、後でインフラストラクチャブランチを増やすことを止めることはありません。

Answer 2

多分submodulesはその使用例のために働くでしょう。

Answer 3

reposの中にreposを作成する必要はありません。実際にSubversionを使用する場合（例えばgitでは似ています）、ブランチを作成したいときはコピー（svn cp）することができます。 Subversionはコピーオンライト（またはコピー時にコピー）を行いますので、別々のディレクトリで作業して別々に扱うことができます。次に、各ブランチ（サブディレクトリ）の変更をマージすることができます。

Answer 4

泥の大きなボールを避ける^ H^H^Hcode。デプロイするコード行ごとに別々のブランチを使用します。ブランチ間で変更を移行する場合は、ブランチごとのコミット間の変更を個別に管理できるため、これが最良の方法です。

共通のコードは、デフォルトブランチ（選択したSCMに応じてマスターまたはトランク）に保存できます。

scmから自動配備を使用して、選択したブランチのみを配備するように設定することができます。

Answer 5

共通のフレームワークを個別のバージョンとあまりにも緊密に結合すると頭痛が発生することがあります。恐らくこれはうまくいくでしょう：

/-+ 
    | 
    +--discovery/ 
    | | 
    | +--index.php 
    | +--main.css 
    | +--main.js 
    +--engine/ 
    | 
    +--1.0-stable/ 
    | | 
    | +--feature.php 
    +--2.0-beta/ 
     | 
     +--feature.php 

発見セクションは、エンジンのバージョンとその現在の状態のリストを管理します。各エンジンバージョンは完全にスタンドアローンになります。ディスカバリー・セクションからエンジン・デプロイメントへの直接的なリンクはありません。これは、現在実行中のバージョンを公表するための単なる方法です。

バージョンコントロールからのデプロイメントは、各エンジンバージョンのディレクトリに対してかなり標準的です。