チームの一部は次のリリース/スプリントに取り組んでおり、残りは本番環境へのリリース前に前のスプリントのテストとバグ修正に取り組んでいます。
次のリリースに取り組んでいる部分は今すぐブランチを望んでいますが、他の部分はできるだけ遅くそれを望んでいます。
まだ分岐していないので、誰かにコミットを待たせるのは好きではありません。また、マージを理解していない人々が時間を無駄にするのも好きではありません。(そして、SVN は名前の変更をマージしません)
ご意見やご提案はありますか？ありがとう
ノート：
これは、GUI がブランチ/マージ操作を行うのを妨げていた 1.4 リポジトリで tortoisesvn 1.6 を使用していたため、過去にはさらに深刻な問題でした。そのため、レポをアップグレードすることでその障害を取り除きました。少なくとも今は、チーム メンバーが簡単にマージできるはずです。
考慮すべきもう1つのポイント：
プログレッシブ コード (最も頻繁に使用されるコードは、新しいものから新しいもの、最新のものへと向かうコードと見なされます) を TRUNK に保持することを検討してください。バグフィクサー チームが使用するために、HEAD (タグ付けされている場合は以前のベースライン リリース) から分岐します。必要に応じて、バグを修正し、トランクから定期的にマージして、最新の開発から更新を取得し続けることができます。
一方、新しいリリース作業は TRUNK で行われ、TRUNK は常に「現在の」環境または「実稼働」環境にあるものを表すために指定できます。以前のリリースで行われた修正を現在のリリースに戻したい場合は、バグ修正ブランチから TRUNK にマージすることができます。
このモデルは、次のリリース タグの後にも繰り返すことができます。
私の経験では、これはバグ修正の数が少なくなるため、マージを最小限に抑えるのに役立ちます。つまり、必要に応じて TRUNK にマージして戻すファイルが少なくなります。ほとんどの場合 (すべてではないと言います :-))、バグ修正に関する開発者の数は少なくなるため、マージが必要なファイルの数も少なくなります。
HTH。
できるだけ遅く分岐します。
特に最新バージョンの TortoiseSVN と SVN クライアントでは、分岐は SVN では面倒なプロセスである必要はありません。VCS とリポジトリに関するある程度の知識が必要ですが、それはソフトウェア開発者にとって必要なはずです。
考慮すべきことは、開発の各フェーズで発生する可能性のある新しいコードと変更の数です。通常、スプリント/リリース段階では、バグ修正段階よりも大きな変更セットが生成されます。これは、すぐにブランチを作成し、少数のバグ修正をマージする方が賢明であることを意味します。ほとんどの場合、分岐を待つと、より厄介なマージが発生します。
また、早期に分岐すると、新機能の単体テストや機能テスト中にスプリント開発者がバグ修正を実行できるため、バグ修正がより多く公開されます。より多くの公開 = より良いバグのない修正。
リリースの機能凍結に入ったら、次のリリースに取り組んでいるチームがあなたが寝かせようとしているものを壊し続けないように、ブランチを実行する必要があります。これ以上分岐を遅らせようとすると、より多くの問題が発生するだけです。
機能ブランチを使用すると、これが簡単になります。すべての修正はトランクで行われ、リリース元の RC ブランチを保持し、リリースのテストを行う前に、トランクからそこへのホールセール マージを行うことができます。フィーチャー ブランチはトランクからマージされ、フィーチャーの準備が整ったときにのみトランクにマージされます。これは、より多くのマージをもたらすように聞こえますが、すべてのマージを非常に単純に保ちます。
これは、DVCS で得られるワークフローと似ていますが、すべてのブランチが開発者のマシンに分散するのではなく、一目瞭然です。
この種の問題には Git/Mercurial を強くお勧めします。:)
しかし、それが選択肢ではないことはわかっているので、この種の問題に対する 100% の優れた答えは実際には存在しないとだけ言っておきます。一般に、分岐と CVS/SVN とのマージは負荷の高いプロセスになる傾向があるため、プロセスのできるだけ後半まで分岐しないことを好む傾向があります。分岐プロセスを延期できる期間が長ければ長いほど、多くの点で有利になります。しかし、新機能に取り組んでいるチームが知っているように、これは非常に長く続く可能性があります...ある時点で、新機能を遅らせることのコストは、マージを延期することの利点を上回ります.
私が現在いる場所では、これにより、新しいバージョンのリリースの 1 ～ 2 週間前 (または場合によってはそれ以下) にブランチが作成されることがよくあります。ただし、正確な時間は、リリースを促進する特定のプレッシャーや、今後のリリースの新機能によって常に異なります。