mercurial - Mercurial自动buld工作流程？

我正在尝试使用Mercurial复制工作流程。看起来这应该是常见的，但我不太确定如何做魔术。

用户A创建变更集A1和A2。用户A没有变更集B或C.
A1和A2被提交给服务器，服务器将它们放入队列中。其他用户B和C的变更集在队列中排在前面。
每个变更集（B然后是C然后是A1 / A2）自动重新定位到主分支，构建，然后被接受到主干（或被拒绝）。
代码库非常大，因此构建需要很长时间。同时，A3和A4由用户A生成。
用户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

git和mercurial通常使用的设置之间存在一个区别：git经常允许对其他人或远程存储库进行变基，修剪和其他重写/破坏性操作 - 默认情况下，mercurial不允许修改操作。

然而，有一种多变的方式：mercurial不久前介绍了phases的概念，特别是不可变阶段 public 和可变阶段草案。你现在可以将存储库声明为 non-publishing （这在我看来是一个但不幸的术语 - 它基本上意味着在那里推送的提交不会成为阶段公开但仍处于草案阶段，因此是可变的。< / p>

因此，将您的“中央”存储库设置为其中一个非发布存储库，告诉所有贡献者使用相当现代的mercurial 并将更改推送到阶段草稿（或确保如此在服务器端挂钩并拒绝推送具有公共阶段的新变更集 - 但这可能有问题）。 Mercurials交换过时标记可确保用户获取有关变更集被弃用的信息以及更换新变更集的信息。

然后，服务器端设置需要注意将接受的变更集的阶段从草稿更改为 public 。

介意：一旦变更集转换为阶段公开，该变更集就变得不可变。并且阶段将传播给所有拉动的人 - 因此甚至将阶段恢复到草案，并且更改或修剪该变更集将不可避免地永久地留下所有带有额外变更集的人的回购，每个人都必须自己手动修剪！

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

Mercurial自动buld工作流程？

1 个答案: