perforce に移行しようとしているかなり大きな SVN リポジトリがあります。約 20,000 のリビジョン、ブランチなどを保持したいのですが、いくつかの初期テストでは、perforce が提供する svn2p4 スクリプトは完全な構造を複製できませんでした。
このツールで成功した人はいますか、それとも私のグーグル検索で見つからなかった人はいますか? ベスト プラクティスとヒントを歓迎します。
perforce に移行しようとしているかなり大きな SVN リポジトリがあります。約 20,000 のリビジョン、ブランチなどを保持したいのですが、いくつかの初期テストでは、perforce が提供する svn2p4 スクリプトは完全な構造を複製できませんでした。
このツールで成功した人はいますか、それとも私のグーグル検索で見つからなかった人はいますか? ベスト プラクティスとヒントを歓迎します。
Vitalii Pokrovskii と Mark Fridrich は、すべての変更セットを perforce にインポートするために「同期して再生」する perl スクリプトである svn2p4 を作成しました。
perforce wikiで見つけることができます。また、2007 年の Perforce User's Conferenceで、これに関するプレゼンテーションを行いました。
2012 年更新: 別の解決策は、p4convert-svn を使用することです。詳細はこちら: perforce サイトの p4convert-svn
fuzzymonk が述べたように、唯一の現実的なオプションは、perl スクリプト svn2p4 を使用することです。私はこれを数回使用しましたが、特に多くのブランチではゆっくりではありますが、うまく機能しました。
このスクリプトで非常に便利な機能の 1 つは、サーバー間の地理的な距離に関係なく、ダウンタイムを実質的にゼロにまで最小限に抑えることができることです。これは、svn2p4 が完全に再開可能であるため可能です。
これは、最後のバックアップ以降に発生したいくつかのリビジョンについてのみ、サーバーを停止する必要があることを意味します。これは、移行が地理的に離れた場所にある場合 (svn サーバーと perforce サーバーが遠く離れている場合) に特に役立ちます。これは、インポートの大部分が、インターネット経由ではなく、おそらく同じマシン上でローカルに行われるためです。
現在、大規模なインポート (20K リビジョン、18GB svn ルート) の最中であり、最初のテストでどのような問題が発生したのか知りたいです。
この問題はおそらく完全に消滅していますが、参考までに、Scott Bilas のブログ投稿 ( http://scottbilas.com/blog/subversion-to-perforce-post-mortem/ ) に多くの有用な情報があります。
彼は、svn2p4 に関する特定の問題のいくつかと、それらを回避する方法について言及しています (そのような回避策が可能な場合)。
Subversion を何年も使用した後、Perforce を使い始めたばかりなので、学習曲線の急勾配の部分にいます。
私の最大のヒントは、それをしないことです。ユーザビリティの観点からは、perforce は svn よりもはるかに劣っています。私は仕事でそれを使用することを余儀なくされており、ファイルベース/Windows エクスプローラーの svn インターフェイスよりもはるかに直感的ではありません。ワークスペースの設定は直感的ではなく、削除するのも困難です。時々混乱し、変更されたにもかかわらず何かをコミットしません。デフォルトではすべてが読み取り専用です。チェックアウトされているが変更されていないファイルをコミットします。私は続けることができました...