我们每年发布三个主要版本,并具有相应的分支:例如 2013A、2013B 和 2013C。当我们创建每个分支时,它都是从默认启动的。每个分支中的更改只能向前合并,例如 2013A -> 2013B -> 2013C -> default。 我们在服务器上有一个推送钩子,用于检查推送的合并方向是否错误,即默认 -> 2013C、2013C -> 2013B 等。
我们还有团队特定的分支,其中一些正在为某个版本开发功能,而另一些正在开发下一个版本,例如默认。当一个团队在发布时,他们会合并到发布分支/从发布分支合并。当团队准备好下一个版本时,他们开始合并到默认分支/从默认分支合并。
前几天我们遇到了这样一种情况,一个新开发人员在团队准备好进入下一个版本之前将默认合并到他的团队分支中,然后将团队分支合并到以前的版本中,即默认 -> TeamBranch -> 2013B。不幸的是,我们的钩子没有考虑到这种情况。
本质上,这就是发生的事情:
2013B A---o---o---o---o---B---o
/ \ / \
Team / o---o---o---C---o---o
/ / \
Default D---o---o---o---o---o---o---o---o
A = 创建 2013B 分支
B = 合并到发布分支
C = 错误合并。每当我们合并到发布分支时,我们都希望检测并阻止这些。
D = 发布分支的第一个共同祖先和默认值。
因此,我重新编写了我们的钩子,以检查当更改合并到发布分支时,它不会向后合并。对于每个合并到发布分支,我检查没有来自前向分支的任何祖先合并。这是我正在使用的 revset 查询:
> hg log -r "limit(descendants(p1(first(branch('2013B')))) and reverse(p2(ancestors(branch('2013B'))) and branch('default')),1)"
这行得通。但是,我们有一个大型存储库(111,000 多个变更集),并且检查需要 30 到 40 秒。我想知道是否有更快/更快/更有效的方法来编写我的 revset 查询,或者我没有看到的另一种方法。