3

プロジェクトの 4 つのバージョンがあります。バージョン 1 ～ 3 は、もともとソース管理下になかった「プロトタイプ」でした (ファイルシステム内に別のディレクトリとして存在します)。バージョン 4 は当初からソース管理下にあり、現在はコミットの長い歴史があります。

これらを組み合わせて、バージョン 1 ～ 3 が個々のチェンジセットになり、それぞれが前の子孫になるようにしたいと考えています。バージョン 4 のルートは、バージョン 3 の子孫になる必要があります (もちろん、バージョン 4 の履歴が崩壊することはありません)。

すべての変更は非公開であり、公開されていません (いわば履歴の書き換えに問題はありません)。

これまでに行ったことと試したこと:
1. プロトタイプ バージョンのディレクトリに新しい hg リポジトリをセットアップしました
2. バージョン 4 のリポジトリをクローンしました
3.hg pull --forceバージョン 1 ～ 3 の無関係なリポジトリを複製されたリポジトリ。

これにより、単一のリポジトリに 4 つの無関係な「ルート」(先祖のない変更セット) ができます。それらを組み合わせると、これらの4つのルートを覚えたくありません。 hg rebaseとは異なり、変更セットを移動してオリジナルを破棄できるようにする必要がありhg mergeます。

ここでは101、「バージョン 1」(親のない単一の変更セット)102のリビジョンとして、および「バージョン 2」のリビジョンとして使用します。

試行 1: 試してみhg rebase -b 102 -d 101ましたが、respone が得られましたnothing to rebase。おそらくこれは、共通の祖先がないためです (これは矛盾しているように感じます...共通の祖先を除く-b 102すべての祖先が含まれますが、この場合は何もありません。)

試行 2: やってみhg rebase -s 102 -d 101ます。これにより、マージの競合が発生します。私はhg revert --all --rev 102、hg resolve -mすべての競合で「バージョン 2」を好むことを示します (ただし、追加/削除が存在する場合に、ある親を別の親よりも優先するのが本当に正しい方法なのだろうか?)。しかし、私がコミットするとき、私は直線的な歴史を持っていません --- リビジョン102はまだそこにあります!

4

3 に答える 3

1

私が知っているよう--tool "internal:other"に、リビジョンに戻すのではなく、リベースで使用する方が良いです。

于 2013-09-05T09:58:50.253 に答える
0

私にとってうまくいったリベースの代替手段は、hg convert拡張機能と--splicemapオプションを使用することです。

実際convertには他のソース管理システム (SVN など) から移行することを目的としていますが、hg から hg に「変換」することもできます。

--splicemap オプションを使用すると、変更セット間の子/親の関係を明示的に設定できます。これを使用して、無関係のリポジトリに由来するブランチを排除しました。Mercurial はこれをうまく処理しているように見えます。たとえば、同じ名前のファイルは、convert/splicemap 操作に続いて連続した履歴を持っているように見えます。

これが必ずしもリベースよりも「優れた」ソリューションであるかどうかはわかりません。奇妙なケース（？）のニッチなアプローチかもしれません。明らかな欠点の 1 つは、大規模なリポジトリの場合、変換手順の実行にかなりの時間がかかる可能性があることです。

スプライスマップのドキュメント。

于 2016-06-29T18:17:53.963 に答える