23

SubversionからMercurialに移行しています。移行を容易にするために、Subversionリポジトリのクローンである中間のMercurialリポジトリを作成しています。すべての開発者はMercurialリポジトリへの切り替えを開始し、変更を中間のMercurialリポジトリから既存のSubversionリポジトリに定期的にプッシュします。しばらくすると、Subversionリポジトリは廃止され、中間のMercurialリポジトリが新しい記録システムになります。

Dev 1 Local --+--> Mercurial --+--> Subversion
Dev 2 Local --+                +
Dev 3 Local --+                +
Dev 4 -------------------------+

私はこれをテストしてきましたが、ローカルリポジトリから中間のMercurialリポジトリに、そしてSubversionリポジトリに変更をプッシュすると、問題が発生し続けます。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png

ローカルマシンには、コミットされ、中間のMercurialリポジトリにプッシュする準備ができているチェンジセットがあります。ここでは、ハッシュ625を使用したリビジョン＃2263であることがわかります。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png

このチェンジセットのみをリモートリポジトリにプッシュします。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png

これまでのところ、すべてが良さそうです。チェンジセットがプッシュされました。

hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

ここで、リモートリポジトリに切り替えて、作業ディレクトリを更新します。

hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed

次に、変更をSubversionにプッシュします。これは、うまく機能します。この時点で、変更はSubversionリポジトリにあり、ローカルクライアントに注意を戻します。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png

ローカルマシンに変更をプルします。は？2つのチェンジセットがあります。私の元のチェンジセットは現在、ローカルブランチとして表示されます。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png

他のチェンジセットには、新しいリビジョン番号2264と新しいハッシュ10c1があります...

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png

とにかく、ローカルリポジトリを新しいリビジョンに更新します。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png

私は今切り替えられました。

代替テキストhttp://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png

それで、私はついに「発信チェンジセットを決定してマークする」をクリックします。ご覧のとおり、Mercurialは、以前のチェンジセットがすでにプッシュされていても、プッシュしたいと思っています。

明らかに、私は何か間違ったことをしています。

また、2つのリビジョンをマージすることはできません。ローカルマシンで2つのリビジョンをマージすると、「マージ」コミットが発生します。そのマージコミットを中間のMercurialリポジトリにプッシュすると、変更をSubversionリポジトリにプッシュできなくなります。私は次の問題に行き着きます：

hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

hg push
pushing to svn://...
searching for changes
abort: Sorry, can't find svn parent of a merge revision.

マージをロールバックして、動作状態に戻す必要があります。

私は何が欠けていますか？

4

3 に答える 3

22

あなたは何も悪いことをしていません。実際、あなたの状況では、あなたが見ている振る舞いは期待される結果です（新しいMercurialユーザーにとって多少混乱するかもしれませんが）。

hgsubversionは、次の2つの点で非常に優れています。

  1. svnの外部で変更を交換せずに、SubversionのクライアントとしてMercurialを使用する
  2. SubversionリポジトリをMercurialに変換する

あなたはそれをより一般化されたゲートウェイとして使用しようとしていますが、これははるかに難しい問題です。Subversionは非常に厳格な世界観を持っており、その中で作業する必要があります。問題の真実は、リビジョンがSubversionからプルされた後、hgsubversionを使用する場合にのみ、リビジョンハッシュを最終として表示できるということです。したがって、開発者が仲介者としてSubversionを使用せずに、Mercurialリポジトリ間でチェンジセットを直接共有する場合、これが発生します。

リベースは自動であり、非常に基本的な理由でオプションではありません。Subversionは、プッシュするとそのリベースを実行します。プッシュしたときにプルされていない変更があった場合、Subversionはそのリベースを実行し、成功した場合（ばかげて単純なリベースアルゴリズムを使用）、リベースが発生したことを示すことなくコミットを受け入れます。2つの異なるモデルにパッチを適用しています。

全員を一度にMercurialに移行することをお勧めします。このようなハイブリッドアプローチでは、短期的にはMercurialの使用が必要以上に難しくなり、DVCSを初めて使用するユーザーを混乱させる可能性があります。

于 2010-03-25T15:15:57.860 に答える
3

まず、このような詳細な質問を読んで、どんなに嬉しかったかをお話ししましょう。:)

hg pushリモートからsvnリポジトリにtoを実行すると、問題が発生します。これがあなたの例からの出力です：

hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed

私はhg-subversionユーザーではありませんが、その出力は、要求されたプッシュを実行するプロセスで、svnリポジトリから変更をプルし、新しいリビジョンを見つけて、（の子孫）の後に変更rebaseセットを実行することを示しています10c1新しくプルされたリビジョン。rebaseコマンドは、分岐履歴を取得して線形履歴に変換しますが、そうすることで、チェンジセットの親が変更され、ハッシュが変更されます。これは、あなたに起こっていることのように見えます。

繰り返しますが、hg-subversionユーザーではないので、そのプル/リベースが常に発生することになっているのか、それがどのように機能するのかはわかりませんが、hgsubversionwikiページには次のように書かれています。

通常のMercurialコマンドを使用して、このリポジトリを操作できます。特定のブランチに一連のコミットがあり、それらをそのブランチの先端に移動したい場合は、作業の先端でhg rebase --svnコマンドを使用すると、それらのチェンジセットが自動的にリベースされます。新しいアップストリーム作業。

通常は自動ではないように聞こえます。

あなたのイントロからはよくわかりませんでしたが、新しいチェンジセットはまだsvnで作成されていますか、それともMercurialでのみ作成されていますか？

それらがMercurialでのみ作成されている場合、回避策の1つは、リモートシステムにsvn-gatewayリポジトリを設定し、そこからプッシュを実行し、そのリポジトリからMercurialにプルバックしないことです。その場合、そのリポジトリ内のチェンジセットは、リベースのために異なるハッシュIDを持ちますが、それらはメインのリモートリポジトリとエンドユーザーシステムに逆流しません。

ただし、より大きな修正は、「hg push svn：//..がすべてのアウトバウンドチェンジセットをリベースしている」理由を理解することです。その1つに答えると、動作が停止します。

于 2010-03-24T04:23:52.490 に答える
1

現在、graftコマンドを使用してこれと同様のことを行っています。マージチェンジセットをプッシュする必要がないように、プッシュする前にすべてのチェンジセットを効果的に再作成します。

私たちの目標は、Subversionを使用するプロジェクトにクリーンに貢献することです。

  • すべての変更に対してSubversionブランチを作成します。Mercurialで入手してください。
    $ cd [svn-checkout] ; svn cp trunk branches/hg-bridge
    $cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge

  • 新しい変更については、ローカルリポジトリを確認してください
    $hg in [repo] # shows <rev> IDs you can use later

  • ローカルリポジトリからsvnに入れたい変更をプルします
    $hg pull [repo]

  • 貢献したいすべての変更を移植します。
    $hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>.
    すべての回転数を個別に指定する必要があります
    が、1つのコマンドで複数の回転数を移植できます。

  • プッシュするものを確認してください：
    $hg outgoing

  • 変更をプッシュします。
    $hg push
    これにより 、関連のないプルされたリビジョンが表示される場合 があり、バックアップバンドルへのパス（コメントはGPLv2以降でも使用できます）とともに、新しいリビジョンがプルされたものとして表示されます。

于 2012-05-25T08:48:48.127 に答える