Mercurial を使用しているときに、現在の作業コピーを特定のリビジョンで変更したい場合は、次のようにします。
$> hg revert good_revision
$> hg commit -m "Now I'm in the good revision"
その後、すべてのファイルがgood_revision状態になり、作業を開始できることがわかります。
これまでのところ、化石では元に戻すことができますが、リポジトリ全体ではなく特定のファイルに対してのみ行うことができ、更新またはチェックアウトは期待どおりに機能しないようです。
リポジトリ全体を特定のリビジョンに戻すにはどうすればよいですか?
私が完全にフォローしているかどうかはわかりませんが、Fossilで「1つのブランチに複数のヘッド」の状況を作成できるようにすることを望んでいると思います. はいの場合、Fossil はこれをサポートします。ブランチのヘッドを「リーフ」と呼び、このプロセスを「フォーク」と呼びます。
そのために、あなたは
fossil update good_revision
その後
fossil commit --allow-fork
スポーンfossil uiしてブランチに移動すると、2 つのリーフがあることがわかります。
これで、当時のリーフを閉じることができます。
これはサポートされていますが、推奨される方法ではないようです。代わりに、Fossil は、変更を破棄するためのかなり独特なアプローチを推奨しています。
「悪い」リーフのブランチの名前を「mistake」に変更します (または、ブランチがまだ存在しない場合は作成します)。これを行うことで、結果のサブリーフを間違いとして効果的に「マーク」できます。
「間違い」という名前は単なる慣例であることに注意してください。このブランチは、新しく作成されたリポジトリには存在しません。
「悪い」リーフを閉じます。
を使用して最後の良好な状態に戻り、fossil updateハッキングを続けます。
その「最後に有効な」コミットは、その親コミットのブランチ タグを引き続き継承するため、記録する次のコミットもそれを継承し、ブランチ「ミス」にはなりません。
例として、SQLite リポジトリでどのように表示されるかを確認してください。このブランチには、コミットのさまざまな短いチェーンがたくさんあります。これも参照してください。
私があなたの質問を正しく理解していれば、開発サイクルのどこかに問題があり、1 つ以上のリビジョンを既知の適切なリビジョンに戻し、それを使い始めたいと考えています。さらに、そのリビジョンをトランクにしたいと考えています。Fossil でのアプローチは、Mercurial のアプローチと似ています。
fossil revert -r good_revision
fossil commit -m "Now I'm in the good revision"
これにより、作業ディレクトリ内のファイルが指定されたリビジョンのファイルに置き換えられます。コミットは、作業中のブランチにそれらをコミットします (この例ではトランクであると想定しています)。リビジョン番号を指定しない場合、最後にコミットされたバージョンが使用されます。
revertコマンドのより一般的な使用法の 1 つは、1 つのファイルをロールバックすることです。
fossil revert -r good_revision my_file
(or)
fossil revert my_file_from_the_last_commit
ただし、最初の例で示したように、ファイル名を省略すると、すべてのファイルが元に戻されます。詳細については、https://www.fossil-scm.org/index.html/help?cmd=revertを参照してください。
最新の回答で申し訳ありませんが、何か他のものを探しているときに質問に出くわしました。Fossil に保存されている以前にコミットされたバージョンに戻す方法を誰かが調べている場合に備えて、これを投稿します。
質問を理解していると思うものに対する私のわずかに異なる解決策（言い換えると、このブランチ/トランクの現在のリーフよりも古い「good_revision」で作業する方法、これをbad_leafと呼び、「good_revision」以降の変更を悪いものとして扱う方法)、これは 2 つのバージョン間の差分を適用するのと同じようなものですが、順序が逆になります。
デフォルトの最後の一般的なコミットの代わりに、bad_leaf からのベースラインを使用して、good_revision からの (空の) フォークをマージします。したがって、適用される差分は、作成した good_revision フォークに戻った元のブランチの差分であり、それらが既に適用されていることはわかりません。最新のものをベースラインとして使用すると、それらが既に適用されているため、そうでなければすべての変更を無視するようになるものを「非表示」にします。
fossil update good_revision
fossil commit --allow-fork --allow-empty
# note the uuid from that commit (for use as forked_basis below)
fossil merge -f --integrate --baseline bad_leaf forked_basis
もちろん、一度幸せになると、
fossil commit
「間違い」と呼ばれるべきブランチを作成しません。good_revision から bad_leaf に bad_leaf への逆差分を適用して元の場所に戻すだけで、以前と同じ (新しい) リーフにコミットし続けることができます。 bad_leaf で。
diff上記のコマンドが一致した後のチェックアウトと比較した、元の good_revision でのチェックアウトに対する (fossil diff ではなく、ストレート gnu) 。ファイルを失った空のディレクトリを除きますが、化石は死んだディレクトリを追跡/整理しません。
注意: 私は化石をそれほど長く使用しておらず、cvs/svn/git/hg/perforce/clearcase で慣れ親しんできた一般的な方法とはいくつかの点で異なります。
この回答を追加する理由: 既存の回答を理解するのが難しく、結果として自分自身がそれらを正しく行うことができるかどうか確信が持てませんでした。