2

2013A、2013B、および 2013C など、共同で対応するブランチとともに、年に 3 つのメジャー リリースがあります。各ブランチを作成すると、デフォルトから開始されます。各ブランチの変更は、前方にのみマージする必要があります(例: 2013A -> 2013B -> 2013C -> デフォルト)。 サーバーには、プッシュされたマージが間違った方向 (デフォルト -> 2013C、2013C -> 2013B など) にあるかどうかをチェックするプッシュ フックがあります。

また、チーム固有のブランチもあり、リリースの機能に取り組んでいるブランチもあれば、デフォルトなどの次のリリースに取り組んでいるブランチもあります。チームがリリースに取り組んでいる間、リリース ブランチとの間でマージします。チームが次のリリースに取り掛かる準備ができたら、デフォルト ブランチとのマージを開始します。

先日、チームが次のリリースに移行する準備が整う前に、新しい開発者が default を自分のチーム ブランチにマージし、チーム ブランチを以前のリリース、つまり default -> 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クエリを作成するためのより高速/高速/効率的な方法、または私が見ていない別のアプローチがあるかどうかを知りたかったのです。

4

2 に答える 2

0

マージを検出するにはC、使用できるはずです

$ hg log -r "parents(branch(Team) and merge()) and branch(default)"

これによりdefault、 にマージされた の変更セットが得られますTeam。存在する場合は、誰かが誤ってチーム ブランチにマージされています。チーム ブランチの観点からこれを攻撃する必要があると思います: リリース ブランチへの/からのマージを禁止することはできません。

チーム ブランチが一貫した命名スキームに従っている場合 (そうするべきです)、正規表現とbranch()述語を使用してブランチを選択できます。何かのようなもの

$ hg log -r "branch('re:team-.*')"

で始まるブランチに一致しteam-ます。

于 2013-11-12T08:27:36.673 に答える