Accurevのパフォーマンスはどうですか？

Question

Accurev の現在のバージョン（4.7）のパフォーマンスはどうですか？

• 100 MB、GBあたりのチェックアウト時間
• ファイル数またはmbごとにコミットする時間？
• 100以上のストリームがある場合のGUIの応答性

Accurevのデモがありましたが、ストリームはコード/プロジェクトのワークフローをモデル化する軽量な方法のように見えます。ストリームのバックエンドについてAccurevを称賛し、パフォーマンスについて不満を言う人がいます。 Accurevはパフォーマンスに取り組んできたように見えますが、実際のデータをいくつか取得して、それがdemos-well-runs-less-wellの場合ではないことを確認したいと思います。

Accurevのパフォーマンスの逸話やテストからの（さらに良い）データはありますか？

Answer 1

数字はありませんが、パフォーマンスの問題に気付いた場所を説明できます。

通常、ビルドではソース管理から30〜40Kファイルを使用します。現在、私のワークスペースには、ビルド中間ファイルと出力ファイルを含む66Kを超えるファイルがあり、サイズは15GBを超えています。 AccuRevの応答性を維持するために、要素を無視を積極的に使用して、AccuRevは* .objなどの中間ファイルを無視します。さらに、タイムスタンプの最適化を使用します。一般に、更新の実行は迅速ですが、プロジェクトのサイズは通常5〜10人であるため、毎日更新する場合、通常は数十個のファイルしか保存されません。誰かが多くのファイル速度に影響を与える変更を加えたとしても、問題はありません。一方、30K以上のすべてのファイルの完全な読み込みは遅いです。これを行うことはめったにないので、私には時間がありません。また、まれに、昼食や会議に行くときに人口を管理します。私はそれが最大10分になると予想しています。一般に、ソースファイルはすぐにダウンしますが、10〜20 MBの大きなバイナリファイルがあり、それぞれ数秒かかります。

除外ルールと無視要素が正しく構成されていない場合、AccuRevはこのサイズのワークスペースの更新を実行するのに数分かかることがあります。他の開発者が速度について不平を言うのを聞いたとき、何かが間違って設定されていることを知っており、それをまっすぐにしています。

1年ほど前、プロジェクトの1つが25K +ファイルでブーストを更新し、リポジトリにFireFoxを追加しました（サイズを忘れて、ブーストを小さく見せました。）彼らはまたICUを追加し、多くのソフトウェアを書き、無数のファイルを修正しました。思い出すと、ストリームには約250K以上のファイルがありました。残念ながら、すべてのプロジェクトを共有できるように、すべての優れたコードをルートに昇格させる必要があると判断しました。これは、AccuRevがうまく処理できる範囲を少し超えていることが判明しました。すべての変更を促進するのに数時間かかりました。 FireFoxがプロモートされると、残りはスムーズに進みました。おそらく、100,000を超えるファイルを持つ単一のトランザクションが問題でしたか？

最近、boostを更新したため、25K +ファイルを保持および昇格する必要がありました。 1〜2分かかりましたが、ファイルの数とバイナリのサイズを考えると不合理ではありません。

ストリームの数については、800を超えるストリームとワークスペースがあります。ここでのパフォーマンスは問題ではありません。一般に、多数のストリームをナビゲートするのが難しいと思うので、自分のワークスペースと関心のあるストリームのみのフィルターされたビューを実行します。しかし、フィルターされていないリストを見てパフォーマンスを確認する必要がある場合は

最後の注意事項として、AccuRevのサポートは素晴らしいです-それらを空の声と呼びます。たびたびAccuRevを使用して自分の足で撮影し、物事を修正する方法について無知である。ほとんどの場合、私たちは何か愚かなことをしてから、それを修正するために何か愚かなことを試みました。最終的には、サポートリクエストを送信し、次に電話またはgotoミーティングで正義へのステップを順を追って説明します。私は忙しい一日を過ごしているので、理解する時間がないだけの些細なことでさえ彼らに連絡しました、そして彼らは親切に私にRTFMに告げるのではなくそれを歩きます。

Answer 2

編集2014：RealVNCの商用バージョンを使用することで、許容できるX-Windowsパフォーマンスを得ることができます。

元のコメント：この回答は、4.7だけでなく、Accurevのすべてのバージョンに適用されます。まず、Webクライアントを使用できる場合、GUIのパフォーマンスは良好です。 Webクライアントを使用できず、GUIパフォーマンスが必要な場合は、Windowsを使用するか、すべての開発者を1か所、つまりAccurevサーバーがある場所に配置することをお勧めします。 WANを介してX-WindowsでGUIを実行してみてください。忘れてください：基本的なポイントアンドクリック操作の経験は数十秒または数分でした。これは、約800マイル離れたかなり良好なWAN上で、ほぼ最適なping時間です。これはAccurevの障害ではなく、X-Windowsの障害であり、WANを介した他のXアプリケーションでも同様の問題が発生する可能性があります。可能であれば、基本的なXを避けてください。現在、私たちはできませんし、WANユーザーはコマンドラインのみに強制的に委任されています。基本的な問題は、Accurevが集中化されており、光の速度を上げることができないことです。 Accurev Replication Serverを実行することでWANの遅延を回避できると思いますが、VPNを介して一人のオフィスにリモート開発者がいる場合、それでも問題に適切に対処できません。皮肉なことに、レプリケーションサーバーがこの中央集中型VCSをDVCSの形式にいくらか変えているのです。レプリケーションサーバーがない場合、恐ろしいが多少実行可能な回避策は、rsyncなどのデルタ同期ツールを使用して、GUIを実行できるローカルマシン間でソースツリーを同期することです（つまり、GUIで直接実行するGUI WindowsまたはLinuxラップトップ）、および実際に作業しているマシン（たとえば、1,000マイル離れたUNIXマシン）。別のオプションは、VNCのようなものを使用することです。これは、XよりWAN上で動作し、Accurevサーバーの場所にある仮想デスクトップに接続し、そこからXを使用します。私の職場では、複数のチームがMercurialをサイドで使用し、厳密に必要な場合にのみAccurevに昇格しています。 Stephen Nuttが上で指摘したように、他の必要な作業はタイムスタンプの最適化を使用して無視することです。また、Accurev管理者もいます（はい、それをベビーシッターに使用する必要があります）。製品のコア部分を形成し、バージョン管理が必要であるという事実にもかかわらず、大量のファイルを含める必要がある場合に苦情を申し立てます。独自の結論を導き出します。