2

Mercurialリポジトリ（「Redmineリポジトリ」と呼びます）を備えた専用の問題追跡（Redmine）マシンがあります。Redmineはそのリポジトリを使用するように設定されており、私が理解している限り、Redmineはそのリポジトリに変更を加えることはありません。すべての開発者は（最終的に）変更をそのリポジトリにプッシュします。

また、コードを実行できる専用の本番マシンもありますが、コードの変更には使用されません。

2つの選択肢があります。

  1. 本番マシンに別のMercurialリポジトリを設定します（「本番リポジトリ」と呼びます）。新しい本番リリースが承認されたら、変更をRedmineリポジトリから本番リポジトリにプルし、ローカル作業ディレクトリを本番リポジトリから適切なリビジョンに更新します。

  2. 本番マシンの既存のRedmineリポジトリを再利用して、そこにMercurialをインストールするためのローカルリポジトリを指定します（Redmineリポジトリは、本番マシンに簡単にマウントできる共有ドライブ上にあります）。新しいプロダクションが承認されるたびに、ローカル作業ディレクトリをRedmineリポジトリから適切なリビジョンに更新します。

オプション＃2を使用すると、余分な「プル」ステップ（Redmineリポジトリから本番リポジトリへ）を取り除くことができ、プロセスがわずかに簡素化されます。しかし、1つのリポジトリが2つのMercurialインストールでローカルであるかのように使用されても問題ないかどうかはわかりません。

この選択（またはこの設定の他の側面）に関するコメントは大歓迎です！

4

1 に答える 1

4

それは悪い考えのように聞こえます。Mercurialは、リポジトリへの読み取りと書き込みをアトミックに保つのに非常に優れていますが、リポジトリが共有ドライブ上にある場合、それを使用しているローカルリポジトリが1つしかない場合でも、ネットワーク共有（特にWindowsの場合）彼らが言うように、物事を常にアトミックにするわけではありません。

理想的には、リポジトリ（作業ディレクトリとリポジトリの両方）は可能な限りローカルであり、プッシュ/プルを使用してネットワーク共有との間でチェンジセットを取得します。それが不可能な場合は、リモートファイルシステムのリポジトリを使用して単一のローカルアプリケーションを使用することをお勧めします。

同じ基盤となるリポジトリを使用して2つのクローンを作成したい場合は、ShareExtensionを確認してください。ShareExtensionはMercurialに付属していますが、上級ユーザーのみを対象としています。

ピギーバックを試みる代わりに、redmineリポジトリに次のようなフックを配置してみませんか？

[hooks]
changegroup = hg push //production/clone

これにより、redmineに到着したチェンジセットが自動的に本番環境にプッシュされます。

于 2012-08-24T02:25:21.093 に答える