Mercurial自动buld工作流程？

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和水银，通常使用的设置之间的一个区别：吉特常常允许垫底，修剪等重写/破坏性操作上的其他人或远程仓库 - 善变默认情况下不和只允许修改操作。

然而，有一个善变的方式：善变的，前一段时间推出的phases的概念，特别是unmutable阶段公共和可变相位草案。现在，您可以声明库为non-publishing（这是一个，但在我眼里不幸的名词 - 这基本上意味着，承诺推动有不会成为阶段公开，但保持同相草案，从而可变

这样设置你的“中心”。存储库作为其中一个非发布存储库，告诉所有贡献者使用合理现代的mercurial 并推动更改作为阶段草稿（或确保在服务器端挂钩并拒绝将新变更集推向公共阶段 - 但这可能是有问题的）。过时标记的水银交换确保用户获得哪些变更集将被弃用的信息以及它们被替换的新变更集的信息。

然后，服务器端设置将需要照顾将接受的变更集的阶段从草稿更改为公开。

注意：一旦变更集转换为公开阶段，该变更集将变为不可变。这个阶段将传播给所有拉动的人 - 因此，甚至将阶段恢复为草稿，并且改变或修剪该变化集将不可避免地永久地离开所有拉动了额外变更集的人的回购，每个人都必须手动修剪它们！

您（以及您所有的贡献者）也可能应该看看evolve extension，它使得处理非发布存储库以及处理和交换可变更改集及其修改更加舒适。