1

他のアプリケーションと共通の 2 つのモジュール「common」および「common-www」を使用するアプリケーション「myapp」があります。

これらは、マスター リポジトリ内のシン シェルとして配置されます。

myapp-master
    myapp
    common
    common-www

各サブレポは、「本番」リポジトリと「トランク」リポジトリを使用して、安定した/デフォルトの構成としてセットアップされます。

安定版 (「運用」) のシンシェル マスターの .hgsub ファイルは次のとおりです。

myapp = https://myhostingprovider/repos/myapp/grp/production
common = https://myhostingprovider/repos/common/grp/production
common-www = https://myhostingprovider/repos/common-www/grp/production

マスター リポジトリ自体は次の場所にあります。

https://myhostingprovider/repos/myapp/master/production

これは素晴らしいことです。アプリケーションとサブモジュール全体で一貫したバージョン管理を備えた単一のマスター リポジトリがあります。

問題は、.hgsub ファイルが異なるリポジトリを指す必要があるため、マスター リポジトリの安定した/既定のビューを維持できることです。

myapp = https://myhostingprovider/repos/myapp/grp/trunk
common = https://myhostingprovider/repos/common/grp/trunk
common-www = https://myhostingprovider/repos/common-www/grp/trunk

.hgsub ファイルに絶対パスを配置する必要があるため、完全に独立した 2 つのシンシェル マスター リポジトリ (開発用と運用用) ができてしまい、リリース サイクル中に開発から運用に変更をプッシュすることはできません。

このリモート ホスティングのマスター リポジトリ アプローチは、共有ライブラリの典型的なものですか? 別の作業方法をお勧めできますか (hgsub パスが絶対パスであるリモート ホスティングに関して)?

何か考えはありますか？

4

2 に答える 2

1

1) セットアップはそのまま完全に使用可能です。開発と本番の間でコードの変更をマージする場合は、影響を受けるサブリポジトリを個別にマージするため、myapp のトランクから本番にマージします。そして、一般的です。とありがち～www。このアプローチはローテクであり、マージは単純なリポジトリ間で行われるため、単純な Mercurial です。

2 つのマスター リポジトリは、開発/運用ブランチ内のアプリケーションとモジュール全体で一貫したバージョン管理を引き続き提供しますが、マージを行う際に直接使用されることはありません。

私はこのアプローチを自分で使用します。1 回の uber マージではなく 3 回のマージを行いますが、利点は、各マージが簡単に実行および理解できることです。

2) .hgsub 参照は、リポジトリ ホスティングを使用しているという理由だけで絶対的である必要はありません。実際、シェル マスター リポジトリの推奨事項は、すべての hgsub 参照が foo=foo のように自明であることです。

https://www.mercurial-scm.org/wiki/Subrepository#Use_.27trivial.27_subrepo_paths_where_possible

相対参照は常にマスター リポジトリに対して相対的であるため、単純な参照では、リモート サーバーのレイアウトがローカル サンドピットのレイアウトと一致する必要があります。

たとえば、サーバー上で次のことができます。

myapp-production-master
    myapp
    common
    common-www
myapp-trunk-master
    myapp
    common
    common-www

3) 別の方法として、わずかに異なるレイアウトを使用します。これにより、重要な .hgsub 参照が生成されますが、マスター プロジェクト間でサブリポジトリを簡単に組み合わせて一致させることができます。

サーバーでは、ブランチごとにグループ化します。新しいブランチを作成すると、事実上、フォルダーが複製されます。ソース リポジトリの横に (複数の) マスター プロジェクトがあります。たとえば、サーバー上のプロダクション ブランチ フォルダーは次のようになります。

production
    myapp
    common
    common-www
    specific-mac
    specific-win
    myapp-mac-master
    myapp-win-master

myapp-mac-master の .hgsub は次のようになります

myapp = ../myapp
common = ../common
common-www = ../common-www
specific-mac = ../specific-mac

production/myapp-mac-master のクローンを作成すると、ローカル ディスクに移動します。

myapp-mac-master
    myapp
    common
    common-www
    specific-mac
于 2012-08-18T02:40:35.937 に答える
1

私が検討しているもう 1 つのオプションは、シンシェルリポジトリに関するアドバイスを無視し、各依存モジュールのデフォルトURL をマスター プロジェクトの安定したリポジトリから直接参照することです。

myapp (「安定した」リポジトリ)

myapp (stable)
    contrib
        common (default)
        common-www (default)
        module x (default)
        module y (default)
        ...
    src
        myapp-specific source (stable version)

myapp (「デフォルト」リポジトリ)

myapp (default)
    contrib
        common (default)
        common-www (default)
        module x (default)
        module y (default)
        ...
    src
        myapp-specific source (default version)

したがって、これらは直接関連するリポジトリであり、開発と本番の間でプッシュ/プルできます。

「安定した」アプリケーションに「デフォルト」のリポジトリを指すサブリポジトリがあるという点で、明らかに問題があります。ただし、マスター リポジトリはサブリポジトリを最新バージョンに自動的に更新しないため、これは手動で処理できます。「共通」の安定バージョンへの更新に続いて、サブレポは正しいリビジョンに手動で更新されます。

于 2012-08-20T14:15:46.297 に答える