複雑なSVNブランチ階層をMercurialに移行

Question

私たちのチームは、適度なサイズのアプリケーションを管理するためにSVNを使用してきましたが、SVNリポジトリの基本的な標準レイアウトに従った複雑な階層のブランチとタグが構築されました。より多くの入れ子になっている：

 
    |-trunk 
    |-branches 
    | |-releases 
    | | |-releaseA 
    | | `-releaseB 
    | `-features 
    |  |-featureX 
    |  `-featureY 
    |-tags 
    |-releaseA 
    | |-beta 
    | `-RTP 
    `-releaseB 
     |-beta 
     `-RTP  

（機能ブランチは明らかに一時的な枝ですが、我々は近い将来に一度それらのすべてを閉じるすることは可能ではないだろうとして考慮されるそれらを取らなければならない）

いくつかの理由がありますが、主に合併が増加する痛みになっているため、私たちは考慮していますMercurialに切り替える。

私たちが現在直面している主な問題は、歴史を失うことなく既存のコードベースを移行することです。私はいくつかの移行ツール（例えばyasvn2hg、hg convert、svn2hg）を試しましたが、yasvn2hgが最も有望でしたが、ネストされた階層を扱うことはできないようですが、ブランチとタグは1つのフラットディレクトリそれぞれ、

という名前の枝の間の選択のいずれかのソリューションが高く評価されるように、古いSVNの枝の変換対象としてが、この場合の制限要因ではないかクローン。私たちは現在、両方のオプションと、現在のプロセスにどのように適合するかを実験していますが、まだ決定していません。私は明らかに、その問題に関する同様の設定での推奨や経験にも興味があります。

だから、このような入れ子SVN分岐階層をMercurialに変換する最良の方法は何ですか？

一度に1つのブランチを別々のリポジトリに変換するのは非常に迷惑で、ツールが歴史的なマージをどのように処理し、認識する必要があるかによって最初の適切なアプローチであるかどうかはわかりません他のすべての支店？

Answer 1

私が読んだ優秀な記事です。 http://ww2.samhart.com/node/50

Answer 2

mercurial mailing listで本当にそのような質問をする必要があります。これは、Mercurialの開発者が抱いているところで、時間の経過とともに多くのSubversion移行に関する質問がありました。

言われていること

、recent changeはあなたを助けるかもしれない - それはあなたを聞かせていると主張

[...]も、最もひどくmismanagedのリポジトリを修正し、うまく構造化Mercurialのリポジトリにそれらを回します。

私は自分自身で試してみませんでしたので、あなたの正確なケースでどれほど効果的かについてはコメントできません。