Mercurial —古いバージョンに戻し、そこから続行します

プロジェクトでMercurialをローカルで使用しています（他の場所へのプッシュ/プルが行われない唯一のリポジトリです）。

今日まで、それは線形の歴史を持っています。しかし、私が現在取り組んでいることは、ひどいアプローチであり、開始する前のバージョンに戻って、別の方法で実装したいと考えています。

Mercurialのbranch/ revert/ update -Cコマンドと少し混乱しています。基本的に私はバージョン38（現在は45）に戻し、次のコミットに38を親として持ち、そこから継続したいと考えています。リビジョン39-45が永久に失われるか、それとも最終的に自分自身の行き止まりのブランチになるかは気にしません。

どのコマンド/コマンドセットが必要ですか？

hg update [-r REV]

後でコミットする場合、新しいブランチを効果的に作成します。次に、このブランチでのみ作業を続けるか、最終的には既存のブランチをマージします。

コマンドのチートシートは次のとおりです。

• hg update作業コピーの親リビジョンを変更し、この新しい親リビジョンに一致するようにファイルの内容も変更します。つまり、更新したリビジョンから新しいコミットが引き継がれます。

• hg revertファイルの内容のみを変更し、作業コピーの親リビジョンのみを残します。通常はhg revert、ファイルに加えたコミットされていない変更を作業コピーに残したくない場合に使用します。

• hg branch新しい名前付きブランチを開始します。名前付きブランチは、チェンジセットに割り当てるラベルと考えてください。したがって、を実行するhg branch redと、次のチェンジセットは「赤い」ブランチに属するものとしてマークされます。これは、特に異なる人々が異なるブランチで作業していて、後でチェンジセットの発生元を確認したい場合に、チェンジセットを整理するための良い方法です。しかし、あなたはあなたの状況でそれを使いたくないのです。

を使用するhg update --rev 38場合、チェンジセット39〜45は行き止まり、つまり、ぶら下がりヘッドと呼ばれます。プッシュするリポジトリに「複数のヘッド」を作成するため、プッシュすると警告が表示されます。誰かがマージを行う必要があることを示唆しているので、そのような頭を残しておくのは一種の失礼なので、警告はそこにあります。しかし、あなたの場合、あなたは単に先に進むことができます、そしてhg push --forceあなたは本当にそれをぶら下げたままにしたいので。

リビジョン39-45をまだどこかにプッシュしていない場合は、非公開にしておくことができます。これは非常に簡単です。hg clone --rev 38 foo foo-38リビジョン38までしか含まれていない新しいローカルクローンを取得foo-38できます。作業を続け、作成した新しい（適切な）チェンジセットをプッシュできます。fooクローンには古い（悪い）リビジョンが残っています。（クローンの名前は自由に変更できます。たとえば、footo foo-badやfoo-38to fooなど）。

最後に、使用hg revert --all --rev 38してコミットすることもできます。これにより、リビジョン38と同じように見えるリビジョン46が作成されます。その後、リビジョン46から作業を続けます。これにより、履歴と同じように明示的な方法でフォークが作成されることhg updateはありませんが、一方で、複数の頭。hg revertすでにリビジョン45に基づいて自分で作業を行っている他の人と共同作業をしている場合に使用します。それ以外の場合は、hg updateより明確です。

コミットとプッシュを行った直後に、ファイルを1つだけ前のリビジョンに戻す必要がある場合に遭遇しました。これらのリビジョンを指定するための省略構文は他の回答ではカバーされていないため、これを行うためのコマンドを次に示します

hg revert path/to/file -r-2

これ-2は、最後にコミットする前のバージョンに-1戻ります。使用すると、現在コミットされていない変更が元に戻ります。

私見、hg strip -r 39このケースによく合います。

これは、mq拡張を有効にする必要があり、Martin Geislerが推奨する「複製リポジトリ方法」と同じ制限があります。ローカルリポジトリ。

使用hg update -r REVした後、プッシュすることができるようにその変更をコミットする方法についての答えは明確ではありませんでした。

更新後にコミットしようとしただけでは、Mercurialは変更がないと考えています。

最初にファイルを変更する必要があり（READMEなどで）、Mercurialが新しい変更を加えたことを認識し、それからコミットしました。

これにより、前述のように2つのヘッドが作成されました。

プッシュする前にもう一方の頭を取り除くために、私はNo-Op Mergesステップに従ってその状況を改善しました。

その後、プッシュすることができました。

上記の回答は最も役に立ち、多くのことを学びました。ただし、私のニーズに対して、簡潔な答えは次のとおりです。

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

ここ${1}で、リビジョンの番号またはブランチの名前です。これらの2行は実際にはbashスクリプトの一部ですが、手動で実行したい場合は、それ自体で正常に動作します。

これは、リリースブランチにホットフィックスを追加する必要があるが、デフォルトからビルドする必要がある場合に便利です（CIツールが正しく、ブランチからビルドできるようになり、後でリリースブランチも廃止されるまで）。

Tortoise Hg（Mercurial用の無料のGUI）をインストールして使用します。次に、戻したいリビジョンを右クリックし、すべてのコミットメッセージを目の前にして、「すべてのファイルを元に戻す」ことができます。ファイルセットのバージョン間で前後にロールバックすることを直感的かつ簡単にします。これは、問題が最初に発生したときに確認する場合に非常に役立ちます。