Mercurial自動電球ワークフロー？

Question

私はMercurialを使用してワークフローを複製しようとしています。これは一般的であるはずですが、私は魔法のビットをどうやって行うのかについてはあまりよく分かりません。

1. ユーザーAは、変更セットA1とA2を作成します。ユーザーAにはチェンジセットBまたはCがありません。
2. A1とA2がサーバーに送信され、キューに入れられます。他のユーザーBおよびCからの変更セットはキュー内に先にあります。
3. 各チェンジセット（B、C、A1/A2）は自動的にメインブランチにリベースされ、ビルドされ、トランクに受け入れられます（または拒否されます）。
4. コードベースが非常に大きいので、ビルドに時間がかかります。その間、A3とA4はユーザーAによって生成されます。
5. ユーザーAはプルを行い、重複を取得せずにB '、C'および新しいA1 '/ A2を取得します。展開が進むにつれて、A3とA4はトランクの先端に移動します。

ステップ5は、私が最も悩まされているものです。 "git pull --rebase"はチェンジセットが同じであることを認識しているようで、A1/A2は消えますが、Hgでは衝突します。私はHgがまったく同じワークフローであるとは思っていません。開発者がトランクを引っ張り、自分のツリーの手動修正をしなくても、チェンジセットを順番に取得できるようにする必要があります。チェンジセットが拒否された場合の復旧方法についても説明できるワークフローが必要です。戦術を推薦できるこのタイプのワークフローを経験した人はいますか？

ありがとうございました

編集：ここにワークフローのシミュレータがあります。私はチェンジセットが受け入れとスムーズに戻って進行している間に構築を続けることができるという問題を解決する他のワークフローを試みたいと確信しています。

rm -rf master 
rm -rf build 
rm -rf c1 
rm -rf c2 
rm -rf c3 
rm -rf bundles 

# Master repository 
mkdir master 
hg init master 
echo x >> master/m1.txt 
hg -R master add master/m1.txt 
hg -R master commit master/m1.txt -m"m-1" 
echo x >> master/m1.txt 
hg -R master commit master/m1.txt -m"m-2" 
echo x >> master/m1.txt 
hg -R master commit master/m1.txt -m"m-3" 

# Build repository 
hg clone master build 

# Setup first client 
hg clone master c1 
echo x >> c1/client1.txt 
hg -R c1 add c1/client1.txt 
hg -R c1 commit c1/client1.txt -m"c1-1" 
echo x >> c1/client1.txt 
hg -R c1 commit c1/client1.txt -m"c1-2" 

# Setup second client 
hg clone master c2 
echo x >> c2/client2.txt 
hg -R c2 add c2/client2.txt 
hg -R c2 commit c2/client2.txt -m"c2-1" 
echo x >> c2/client2.txt 
hg -R c2 commit c2/client2.txt -m"c2-2" 

# Setup third client 
hg clone master c3 
echo x >> c3/client3.txt 
hg -R c3 add c3/client3.txt 
hg -R c3 commit c3/client3.txt -m"c3-1" 
echo x >> c3/client3.txt 
hg -R c3 commit c3/client3.txt -m"c3-2" 

# Create the 3 bundles simulating the queue; all clients have pushed 
# Hopefully this is done with a push hook 
# All changesets are still draft phase 
mkdir bundles 
hg -R c2 bundle bundles/c2.bundle 
hg -R c3 bundle bundles/c3.bundle 
hg -R c1 bundle bundles/c1.bundle 

# Process first bundle 
hg -R build pull bundles/c2.bundle --rebase 
hg -R build update 
hg -R build push master 

# Client 1 pulls at this point 
hg -R c1 pull master -u --rebase 

# Process second and third bundle 
hg -R build pull bundles/c3.bundle 
hg -R build rebase -b 5 -d 4 
hg -R build pull bundles/c1.bundle 
hg -R build rebase -b 7 -d 6 
hg -R build push master 

# Client 1 pulls again, getting the changesets that were pushed 
hg -R c1 pull master -u --rebase 

Answer 1

のgitとmercurialの通常利用のセットアップの間に1つの違いがあります：gitのは、多くの場合、他の人やリモートリポジトリにリベース、剪定やその他の書き換え/破壊的な操作を可能にする - デフォルトではMercurialはないとだけん操作を修正できます。

しかし、水銀の方法があります：Mercurialはいくつかの時間前phasesの概念、特にunmutable相公共および可変相ドラフトを導入しました。あなたの「中央」セットアップしたがって、それは基本的にコミットが相パブリックになったが、ドラフトの段階でこのように可変残らないプッシュことを意味

- 。あなたは今（それが私の目ではなく、不幸な用語だnon-publishingとしてリポジトリを宣言することができますリポジトリを非公開リポジトリの1つとして使用している場合は、すべての寄稿者に合理的に現代的な水銀のを使用するように伝え、変更をフェーズドラフトとしてプッシュします（または、サーバー側のフックで確認し、 Mercurialsが陳腐化マーカーを交換すると、どのチェンジセットが非推奨となり、新しいチェンジセットが置き換えられるのかについての情報がユーザに得られるようになります。

サーバー側の設定では、受け入れられたチェンジセットの位相をからpublicに変更する必要があります。

マインド：チェンジセットがフェーズパブリックに変換されると、そのチェンジセットは変更不能になります。フェーズはすべての人に引き継がれるので、段階を元に戻しても、チェンジセットを変更またはプルーニングすると、誰もが手動でプルーニングしなければならない余分なチェンジセットを持って引っ張ったすべての人物を必然的に永久に残すことになります。

あなた（およびすべてのあなたの貢献者）は、おそらく非公開リポジトリを扱い、変更可能なチェンジセットとその変更をより快適に扱うことを可能にするevolve extensionを見てください。