私たちは、私たちの製品のバージョン管理のために、Subversion の可能な代替手段として Plastic SCM を調査しています。非常に大規模なソース コード ベースに加えて、非常に多くのバイナリ アセット (主にアート アセットですが、一部のドキュメント、AVI なども含まれます) があります。数字を入れるだけです。trunk ブランチの HEAD リビジョンの svn チェックアウトには 1 時間強かかり、ディスク上のサイズは ~9 GB です。
このような環境で Plastic SCM を使用した経験のある人はいますか? または、Plastic SCM のパフォーマンスと大規模なリポジトリの処理に関するホワイトペーパーまたはケース スタディを参照できますか? グーグルは、客観的な研究にはあまり役立たず、Codice 自身が公開したものにすぎません。また、Perforce がこの環境で非常にうまく機能することも認識しています (以前に使用したことがあります) が、私たちはかなり小規模なチームであり、予算も同様に少なく、Codice はこのシステムを小規模なチームに無料で提供しています (「コミュニティ エディション」)。
テストサーバーにインストールして試してみることに非常に近いです...しかし、他の誰かがそのような環境ですでに試している場合に時間を無駄にしないように、最初に質問を投稿したかったのです。お時間をいただきありがとうございます。
2011 年 2 月 2 日更新: 他の誰かが同様の質問をしてこれを見ている場合に備えての更新です...かなり控えめな Windows 2008 Server マシン (2.8GHz Core 2 Duo、4 GB RAM、リポジトリはローカル ネットワーク上の SAN に保存されている) は、プラスチック リポジトリ用に SQL Server 2008 R2 を実行しています。Subversion のリビジョン履歴のインポートには時間がかかりました - 3 日弱 - ~28000 リビジョン。ただし、 Plastic から新しいブランチの新しいチェックアウトを行うのは非常に高速です。前述のSubversionでは 1 時間以上かかるのに対し、Plastic では 4 分弱です。これまでのところ、私たちは非常に感銘を受けています!