4

シナリオ：

私は2つのHgリポジトリを持っています。1つはSVNリポジトリ、たとえばSVN-trackを追跡し、もう1つは最初からチェンジセットをプルするローカルのpure-Hgリポジトリです。

チェンジセットをpure-HgリポジトリからSVN-trackリポジトリにプッシュし、次に、履歴が適切でまっすぐになるまで、プッシュされたチェンジセットをSVN -trackリポジトリにリベースして、SVNリポジトリにプッシュできるようにします。

SVNにプッシュした後、hgsubversionはチェンジセットをSVNからプルバックし、元のチェンジセットを削除します。これはそれが追跡する方法です、私は集めます（しかし...なぜオリジナルを保持してそれを追跡しないのですか？）。

問題：

さて、これだけ長く待ち続けていると、問題が発生します。SVNチェンジセットをpure-Hgリポジトリに戻したいのですが、元のチェンジセットはすべて、別のヘッドで重複として（ただしノードIDが異なる）戻ってきます。pure-Hgリポジトリに追加したすべてのチェンジセットをリベースできる可能性がありますが、その後は履歴が失われ、実際には、作業が多すぎるように見えます。重複したコンテンツを含むプルされたSVNチェンジセットを使用してローカルにマージすることもできますが、これにより、SVNトラックへのプッシュバックがますます困難になります。

質問：

  • 私が支援なしで神聖にすることができないこのワークフローを実行するためのより良い方法はありますか？
  • そうでない場合、hgsubversionが純粋なHgでSVNからプルバックする元のチェンジセットを置き換えるにはどうすればよいですか？
  • なぜhgsubversion（ほとんどの場合素晴らしい有効化ツール）がSVNチェンジセットをプルして、それらを追跡する必要があるのですか？元のチェンジセットを保持して.hg/svn/rev_map、元のチェンジセットIDを示す行を追加するだけではいけませんか？
  • もしそうなら、これへのトリックは何ですか？
4

1 に答える 1

0

hgsubversion が変更を元に戻す必要がある理由は (私が予想する)、プッシュを行う前に svn に他の変更があった可能性があるためです。svn のすべてのコミットには、変更セットに影響を与える可能性のある「rebase-to-tip」が含まれています。したがって、実際に何が起こったのかと新しい変更セット ID を取得するには、それを引き戻す必要があります。

Perfarce (perforce 拡張機能) は同様のことを行いますが、元の変更を新しいヒントとマージするため、グラフは実際に意味をなします。ただし、私が行ったすべての変更の重複がまだあります。

于 2011-12-01T10:57:37.883 に答える