16

多くの変更セットのそれぞれに対して backout コマンドを使用して、1 つずつ行う最も信頼できる方法はありますか、または[編集: 非連続]変更セット 全体をカバーする 1 つの大きな反転変更セットを作成する方法はありますか?

1つずつの場合、順序は重要ですか? （最後から最初に行くべきですか？）

途中で異なるサブプロジェクト間でマージがある場合、最適な方法は異なりますか?

あなたの経験では、これはスムーズに進む傾向がありますか? :-)

4

5 に答える 5

9

途中でマージがない場合は、個々の変更をすべて（逆の順序で）取り消すか、変更が多数ある場合は、1つの大きな逆パッチを使用して行うことができます。

バックアウトする必要のあるチェンジセットの上に良いチェンジセットがある場合は、最新の悪いチェンジセットの上に逆パッチをコミットしてから、ブランチの先端にリベースします。

1 -- 2 -- A -- B -- C -- 3 -- 4
                     \
                      C'B'A'

$ hg up C
$ hg diff -r C:2 > backout.diff
$ hg import --no-commit backout.diff
$ hg ci -m "Backout A, B, C"
$ hg up 4
$ hg rebase -s C'B'A -d .

マージチェンジセットをバックアウトする場合は問題が発生します。詳細については、このwikiページを参照してください。

このような場合、可能であれば、ブランチをやり直して古い系統を取り除くことを検討してください。そうしないと、ブランチを完全に放棄して、移植または移植によって優れたチェンジセットを回収しなければならない場合があります。

于 2012-05-21T20:30:28.407 に答える
4

私が思いついたのはエレガントではありませんが、取り消す必要のある変更が他の作業に散在していて、内部に分岐しているにもかかわらず、仕事は完了しました。これが私がしたことです。（コメントや改善は大歓迎です。）

すべてのチェンジセットのリストを取得しました（次に、以下のコマンドを生成するために使用しました）。

hg log -r 'keyword(xyz)' --template '{rev}\n'

チェンジセットごとにパッチを生成しました。

hg diff -p -U 8 --reverse -c 15094 > 15094.rev.patch
hg diff -p -U 8 --reverse -c 15095 > 15095.rev.patch
...

次に、各リバースパッチを適用しました。ここでは、順序が重要です。最後から最初までです。

hg import -m "reversing changeset 15302" 15302.rev.patch
hg import -m "reversing changeset 15292" 15292.rev.patch
...

このプロセスは、自動的に実行されなかったマージのために数回中断されました。そこでは、中断したインポートを取得する前に、.rejファイルからファイルに変更を手動で適用してから手動でコミットする必要がありました。

hg histedit -o最後に（別のクローンで...これをすべてクローンで行ったと言いましたか？）とそのfoldコマンドを使用して、リバースチェンジセットのセット全体を1つのチェンジセットに圧縮しました。

これで、後日作業を元に戻すことにした場合に元に戻して適用できるチェンジセットが1つあります（ただし、そのブリッジを渡った場合は、「転送」パッチを順番に少しずつ適用する可能性があります）より良い非難/注釈情報を得るために）

于 2012-05-22T01:01:57.373 に答える
1

これが TortoiseHg でできる方法です。もちろん、コマンドラインでも同じことができます。

この歴史を考えると、変更セット A、B、C を削除したくない場合:

1 -- 2 -- A -- B -- C -- 3 -- 4

リビジョン 2 への最初の更新。

次に、保持したくない後のリビジョンの最初のリベース (この場合はリビジョン 3) をリベースします。

履歴は次のようになります。 

1 -- 2 -- A -- B -- C
      \
       3 -- 4

ここで、リビジョン 4 に更新します。

最後に、「ローカルとマージ」を使用して、リビジョン C をリビジョン 4 にマージします。

この時点で、「マージ ターゲット (その他) リビジョンからのすべての変更を破棄する」オプションを選択することが重要です。

説明は最も論理的ではないかもしれませんが、古いヒント C をデフォルトのブランチにマージして戻すことを意味しますが、変更セット A、B、および C は除きます。

結果は次のとおりです。

1 -- 2 -- A -- B -- C --
      \            /
       3    --    4

コミットして完了です。

于 2016-02-09T13:16:59.570 に答える
0

履歴に「バックアウト」変更セットが必要ない場合は、別のこともでき
ます。リポジトリのクローンを作成しますが、削除したくない最後の変更セットまでのみ作成します。

これを行う方法の例については、Mercurial: 失敗した履歴を修正するを参照してください。

リポジトリがローカルのものである場合は、それですべてです。
しかし、悪い変更セットがすでに中央リポジトリにプッシュされている場合は、そこにあるリポジトリを削除してクローンに置き換えるには、サーバー アクセスが必要です。
さらに、他の誰かがすでに悪い変更セットを含むリポジトリからプルした場合は、削除して再クローンする必要があります (そうしないと、他の誰かが再度プッシュするとすぐに、悪い変更セットが再び中央リポジトリに置かれます)。
したがって、この解決策があなたにとって良いものであるかどうかは、状況によって異なります...

于 2012-05-21T20:44:14.047 に答える