リポジトリを cvs から hg に移行しようとして、ツール cvs2hg を見つけました。うまく機能しているようです (変換はうまくいき、すべてのタグとブランチがあります)。ただし、hg のドキュメントでは、 "fixup commit" によってリポジトリが多少破損したり、少なくとも危険になったりすることについて警告しています。
これはまだ問題がありますか? この警告が書かれてから、おそらく hg または cvs2hg は修正の恩恵を受けています。可能性がある場合、結果の hg リポジトリで、そのような危険な状況にあるかどうかを確認するにはどうすればよいですか?
修正コミットは適切であり、必要です。そして、cvs2hg は hg convert よりもはるかに優れた仕事をします。
しかし、おそらく最初に問題について。CVS リポジトリでは、タグとブランチを使用してさまざまな汚いトリックを実行できます。たとえば、3 つのファイルの今日のバージョン、他の 4 つのファイルの昨日のバージョン、さらに別の 1 か月間のバージョンにタグ付けするいくつかのタグを手動で微調整できます。実際には、「パッチタグ」を作るのを何度もやりました（古いタグがあり、その後さまざまなコミットがあり、バグがあることが判明し、バグを修正し、古いタグで修正タグを作成し、移動しました1〜2個のファイルにあります）。
その結果、履歴がリポジトリ全体に対して取得された場合、リポジトリ履歴の任意の時点で存在する、または存在する予定のリリースを指すタグを取得します。
枝を使って同様のトリックを行うことができます。または、ブランチは「醜い」タグから開始できます。
このような場合、CVS から HG への「自然な」変換はすべて完全に失われます。時間ベースの履歴には、そのようなタグまたはブランチがフックされる可能性のある場所はありません。そして、hg convert は、多かれ少なかれランダムな場所でそのようなタグをバインドし、非常に見苦しい場所で分岐します。
フィックスアップ コミットは単純に、不足しているリビジョンです。適切な場所にバインドされ、リポジトリを特定のタグであるべき状態にする変更を導入する人為的なコミットです。これらを使用して、適切なコードに適切にバインドされた「人工的な」タグとブランチの両方を取得します。
したがって、次の場合：
次に、hg convert ベースの履歴には 4 つの編集変更セット (上記のものと同様) があり、blah_1.0 は不適切なコンテンツの醜い場所にバインドされます。同時に、cvs2hg は、実際に ac(1.1)、bc(1.1)、cc(1.2) がある変更セットを人為的に作成し、そこにタグを付ける「修正コミット」を作成します。歴史上、そのような変更セットは、移植/移植/チェリーピックコミットにかなり似ています。
結果のリポジトリを注意深くチェックして、コード履歴を表し、これらのくだらない修正コミットが含まれていないことを確認する必要があります。
ところで、新しいhttp://www.catb.org/esr/reposurgeon/ツールを確認する価値があるかもしれません。