レビューのために変更セットを送信しました。残念ながら、最初にサンドボックスを更新するのを忘れていたので、そのセットにいくつかの変更を含めていませんでした。
そのため、変更セットに変更を追加するオプションを失いました。
重要な変更が含まれているため、その変更セットを破棄したくありません。また、アトミック ロジック (分割できないロジック) が含まれているため、2 つの変更セットを配信する必要もありません。
「リバース」オプションを使用すると変更セットが編集可能な状態に戻る気がしますが、ここで何をすべきかわかりません。
要約すると、別の変更セットとマージできるように、変更セットを再度編集可能にする必要があります。
誰も私がこれを行う方法を知っていますか?
Thx、あなたたちが支配します！
変更セットがレビューのために送信される前に「完了」していた場合、変更セットの変更可能な状態に戻すことはできないと思います。
その場合、「逆」(つまり、以前のチェンジセットをキャンセルする新しいチェンジセットを実行する) と、それに続く新しいチェンジセットで作業をやり直してレビューのために再提出することが唯一の解決策かもしれません。
ただし、RTC でのコード レビューのこの例に従って、変更セットはレビュー中に ket mutable にする必要があります (元のプログラマーがレビュー担当者のフィードバックに基づいてファイルの新しいリビジョンをチェックインできるようにするため)。
新しい変更セットを作成する必要があります。
私がこれを言う理由は 2 つあります。
1)作業項目ごとに 1 つの変更セットしか持たないという審美的な議論は、実際にはすぐに崩壊します。変更を忘れがちで、バグやレビュー コメントのために修正を加える必要がある場合があります。
2)複数の変更セットがあると、変更が理解しやすくなります。各変更セットには変更の論理セットを含めることができるため、1 つの作業項目に「コードのリファクタリング」、「著作権の更新」 、 「レビューからの変更」の 3 つの変更セットを含めることができます。そうすれば、後で誰かがファイルに注釈を付けるときに、最初の作業項目よりも細かい粒度で何かを得ることができます。
「アトミックロジック」の議論について：あなたのチームが個々の変更セットを配信/破棄する習慣を持っていない限り、おそらく問題にはなりません。RTC プロジェクトでは、論理的に個別の変更を複数の変更セットと複数のコンポーネントに定期的に分割しています。
他のコンポーネントの変更に論理的に依存する変更セットを提供する可能性があることを懸念している場合 (私はときどきそうします)、バグ 150421に協力することをお勧めします。バグ 153907で同様の問題が説明されていますが、はるかに複雑なソリューションが必要です (顧客の圧力なしに実装する可能性は低くなります)。
私は同じ問題に遭遇し、パッチを作成し、変更を破棄してから新しい変更セットを作成することにしました。