汞自动工作流？

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移动到主干的顶端。

第五步是让我陷入困境的第五步。"git拉-重基“似乎认识到变化集是相同的，因此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设置有一个不同之处: git通常允许对其他人或远程存储库进行重基、修剪和其他重写/破坏性操作--默认情况下，mercurial不允许并且只允许修改操作。

然而，有一种变化无常的方法: mercurial在不久前引入了相态的概念，特别是不可变阶段公共和可变阶段草案。现在，您可以将存储库声明为https://www.mercurial-scm.org/wiki/Phases#Publishing_Repository (在我看来，这是一个很不幸的术语--它基本上意味着提交到那里的提交不会变成阶段公共，而是处于草案阶段，因此是可变的。

因此，将您的“中心”存储库设置为非发布存储库之一，告诉您的所有贡献者使用一个相当现代的mercurial ，并将更改作为的阶段草案(或者确保在服务器端挂钩并拒绝使用公共阶段的新变更集的推送--但这可能会有问题)。旧标记的交换可以确保用户获得哪些变更集不再受欢迎，哪些变更集将被替换。

然后，服务器端设置将需要处理将接受的变更集的阶段从草案更改为公共。

思想:一旦改变集被转换为阶段公共，这个变更集就变得不可变。这一阶段将传播到所有的谁拉-因此甚至恢复到起草阶段，和改变或修剪该变化集将不可避免地永久离开的所有谁拉了额外的变化集，每个人将不得不手工修剪自己的回复！

您(以及您的所有贡献者)也应该看看进化扩展，它使处理非发布存储库以及使用和交换可变的变更集及其修改变得更加舒适。