3

SubversionからMercurialに移行しようとしていますが、いくつかの問題が発生しています。最初に少し背景を説明します。

必要なワークフロー：

1つのリポジトリ内に、安定したブランチとデフォルトのブランチの2つだけを配置したいと考えています。

  • 開発はデフォルトのブランチで行われます。
  • バグ修正は安定したブランチにコミットされ、デフォルトにマージされます。
  • すべてのSprintの後に、デフォルトのブランチにタグを付けます。
  • 最終的には、新しいバージョンをリリースできます。このバージョンでは、コード（おそらく最新のSprintタグ）をデフォルトから安定版（update stable、merge Sprint_xyz）に移行し、ブランチ（tag Release_xyz）にタグを付けてリリースします。

また、CI用のJenkinsビルドサーバーで次のジョブが必要です。

  • End-of-Sprintジョブ：このジョブは、デフォルトにSprint_xyzのようなタグを付ける必要があります
  • リリースジョブ：このジョブは、最新の「Sprint」タグの変更を安定版ブランチに渡し、Release_6.0.0などで安定版にタグを付けてリリースをビルドする必要があります。

もう少し背景：

Mercurialは私たちにとって新しいものですが、私たちが見てきたことからすると、これは正気のアプローチのように思えます。開発ワークフローを可能な限り単純にするために、名前付きブランチとクローンブランチよりもリリースをマークするタグを選択しました（単一のマージステップ、単一のチェックアウト、追跡するブランチは2つだけです...）。

私たちはスクラムを使用し、スプリントごとにバージョンをリリースする可能性があります（必ずしもそうとは限りません）。これは、安定したブランチの一部になり、「出荷可能な」リリースになる可能性があります。

私たちが直面している問題（そして私たちがこれに正しい方法でアプローチしているかどうか疑問に思っている...）は次のとおりです。

デフォルトのブランチ（次の貧乏人のグラフの「d」）で作業します。

d -o-o-o-o-

スプリントを終了し、デフォルトで「Sprint1」のタグを付けるEnd-of-Sprintジョブ（Jenkinsを使用）をトリガーします。

d -o-o-o-o-o-
           |
         Sprint 1

Sprint 1をリリースするには、安定したブランチ（'s'）に更新し、Sprint1タグのリビジョンからの変更をマージしてコミットします。

         Sprint 1
           |
d -o-o-o-o-o-
             \
s -o-o-o-o-o-o-

安定したタグを付けてコミットします。

         Sprint 1
           |
d -o-o-o-o-o-
             \
s -o-o-o-o-o-o-o-
               |
             Release 1

デフォルトに更新し、stableをマージします。これは、defaultがstable、commit、pushのスーパーセットのままである必要があるためです。

       Sprint 1
           |
d -o-o-o-o-o-o-o-o-o-
             \   /
s -o-o-o-o-o-o-o-
               |
             Release 1

問題は、.hgtagsを「s」から「d」にマージするときに、Mercurialで競合が発生し、リリースジョブの完了が妨げられることです。結果の.hgtagsには、関連する両方のタグからの情報が含まれている必要があります。私たちはこれに対する解決策を探しており、おそらくいくつかのフックやスクリプトを使用してこれらのタイプのマージの競合を自動化できますが、それ以外の場合は異常ではないように見えるワークフローをサポートするための不要でエラーが発生しやすいハックのようです。

  1. これらの問題に遭遇する原因となる、私たちのアプローチに本質的に何か問題がありますか？
  2. そうでない場合、スクリプト/フックのアプローチに依存することなく、これらの問題を解決するための最良の方法は何ですか？
  3. 私たちのワークフローをサポートするより良いアプローチはありますか？
4

2 に答える 2

3

私は特別な場合のフックに行きます。表示されている問題は、通常のリポジトリデータと同じ方法でメタデータをバージョン管理するというMercurialの哲学に関連しています。これはシンプルで効果的であり、全体的に理解しやすいシステムにつながります。ただし、この場合、マージの競合も発生します。

マージの競合が発生する理由は比較的単純です。この.hgtagsファイルは、一連の行を含む単なるテキストファイルです。各行には、ハッシュと関連するタグが含まれています。1つのブランチで、Sprint 1タグを追加しました。別のブランチで、Release 1タグを追加しました。これらは、あるブランチのファイルの最後に1行が追加され、別のブランチのファイルの最後に別の行が追加されるように表示されます。

次に、2つのブランチをマージします。突然、Mercurialは決定に直面します。どの行を取る必要がありますか？それらの両方を取る必要がありますか？それがソースコードだったとしたら、人間の介入なしにそれを知る方法は本当にありません。

しかし、それはソースコードではありません。それはたくさんのタグです。ルールは、「追加される2つの行が異なるタグを参照している場合は、両方を取得する」である必要があります。しかし、それはMercurialが重要なソースコードになる可能性のある標準的なテキストファイルのように扱っているからではありません。

実際、.hgtagsファイルはマージのためにかなり特別な方法で処理する必要があります。そして、ユースケースをサポートするために、メインラインのMercurialにそのように処理するコードを追加するのは実際には良いことかもしれません。

IMHO Mercurialは.hgtags、同じタグに対して2つの異なるハッシュがある場合にのみ、ファイルが競合警告を表示するように変更する必要があります。もう1つの奇妙なケースは、タグが表示される変更の祖先ではないハッシュを持つタグがある場合です。その場合は、マージを行うときに何らかの形で呼び出される必要がありますが、実際には競合ではありません。

于 2013-03-19T19:02:32.253 に答える
2

タグ付けされたチェンジセットをデフォルトから安定版にマージしていると思われます。代わりにタグ付けチェンジセットをマージする場合、2番目の（おそらくタグ付けも！）チェンジセットをデフォルトにマージするときに、マージの競合が発生しないようにする必要があります。

于 2013-03-19T15:06:12.997 に答える