Accurevの現在のバージョン (4.7) でのパフォーマンスはどうですか?
Accurev のデモを行ったところですが、ストリームは、コード/プロジェクトに関するワークフローをモデル化するための軽量な方法のように見えます。Accurev のストリーム バックエンドを称賛し、パフォーマンスに不満を持っている人がいるのを聞いたことがあります。Accurev はパフォーマンスに取り組んでいるように見えますが、実世界のデータを取得して、デモがうまく実行されていないことを確認したいと思います。
Accurev のパフォーマンスの逸話や (さらに良い) テストのデータを持っている人はいますか?
数値はわかりませんが、パフォーマンスの問題に気付いた場所をお伝えできます。
私たちのビルドは通常、ソース管理から 30 ～ 40K のファイルを使用します。現在、私のワークスペースには、ビルドの中間ファイルと出力ファイルを含む 66K を超えるファイルがあり、サイズは 15GB を超えています。AccuRev の応答性を維持するために、 ignore 要素を積極的に使用して、AccuRev が *.obj などの中間ファイルを無視するようにしています。さらに、タイムスタンプの最適化を使用します. 一般に、更新の実行は迅速ですが、プロジェクトのサイズは通常 5 ～ 10 人なので、毎日更新しても、通常は数十個のファイルしかダウンしません。誰かが多くのファイル速度に影響を与えるような変更を加えたとしても、問題ではありません。一方、30,000 以上のファイルすべてを完全に取り込むには時間がかかります。私はめったにこれを行う時間がありません。まれに、ランチや会議に行くときに populate を実行します。10分くらいかかると思います。一般に、ソース ファイルは非常に迅速にダウンしますが、10 ～ 20 MB の大きなバイナリ ファイルがいくつかあり、それぞれ数秒かかります。
除外ルールと無視要素が正しく構成されていない場合、AccuRev がこのサイズのワークスペースの更新を実行するのに数分かかることがあります。他の開発者が速度について不満を言っているのを聞くと、何かが間違って構成されていることがわかり、それを修正します。
1 年ほど前に、プロジェクトの 1 つが 25K 以上のファイルでブーストを更新し、リポジトリに FireFox を追加しました (サイズは忘れましたが、ブーストは小さく見えました)。また、ICU を追加し、多くのソフトウェアを作成し、無数のファイルを変更しました。全体として、ストリームには約 25 万以上のファイルがあったことを思い出します。残念ながら、すべてのプロジェクトが共有できるように、すべての優れたコードをルートに昇格する必要があると判断しました。これは、AccuRev がうまく処理できる範囲を少し超えていることが判明しました。すべての変更を昇格させるには、数時間のプロセスが必要でした。FireFox がプロモートされた後、残りはスムーズに進んだことを思い出すと、おそらく 10 万ファイルを超える単一のトランザクションが問題だったのでしょうか?
私は最近ブーストを更新したので、25,000 以上のファイルを保持してプロモートする必要がありました。1、2 分かかりましたが、ファイルの数とバイナリのサイズを考えると、不合理ではありません。
ストリームの数については、800 以上のストリームとワークスペースがあります。ここでのパフォーマンスは問題ではありません。一般に、多数のストリームをナビゲートするのは難しいので、自分のワークスペースと興味のあるストリームのみのフィルター処理されたビューを実行します。ただし、何かを見つけるためにフィルター処理されていないリストを確認する必要がある場合、パフォーマンスは問題ありません。
最後に、AccuRev のサポートは素晴らしいです。時々、私たちは AccuRev を使用して自分の足を撃ち、物事を修正する方法がわからなくなってしまいます。ほとんどの場合、私たちは愚かなことをしてから、それを修正するためにもっと愚かなことを試みました。最終的に、私たちはサポート リクエストを提出し、次に彼らが電話または goto ミーティングのいずれかで正義へのステップを順を追って説明していることを知りました。私は忙しい一日を過ごしているので理解する時間がないだけの些細なことについても彼らに連絡しました.
編集 2014: RealVNC の商用バージョンを使用して、許容可能な X-Windows パフォーマンスを得ることができるようになりました。
元のコメント:この回答は、4.7 だけでなく、Accurev のすべてのバージョンに適用されます。まず、Web クライアントを使用できる場合、GUI のパフォーマンスは問題ないかもしれません。Web クライアントを使用できず、GUI のパフォーマンスが必要な場合は、Windows を使用するか、すべての開発者を 1 か所 (つまり、Accurev サーバーがある場所) に配置することをお勧めします。WAN を介して X-Windows で GUI を実行してみませんか? 忘れてください : 私たちの経験では、基本的なポイント アンド クリック操作に数十秒または数分かかりました。これは、ほぼ最適な ping 時間で、約 800 マイル離れたかなり良好な WAN を経由しています。これは Accurev の問題ではなく、X-Windows の問題であり、WAN を介した他の X アプリケーションでも同様の問題が発生する可能性があります。したがって、可能であれば基本的な X は避けてください。現在、それはできず、WAN ユーザーは強制的にコマンドラインのみに追いやられています。基本的な問題は、Accurev が集中型であり、光の速度を上げることができないことです。Accurev Replication Server を実行することで WAN の遅延を回避できると思いますが、VPN を介して 1 人のオフィスにリモート開発者がいる場合、それでも問題に適切に対処することはできません. 複製サーバーがこの集中型 VCS を DVCS の形式に変えるのは皮肉なことです。複製サーバーを持っていない場合、恐ろしくもある程度実行可能な回避策は、rsync などのデルタ同期ツールを使用して、GUI を実行できるローカル マシン間でソース ツリーを同期することです (つまり、GUI をサーバー上で直接実行する)。 Windows または Linux ラップトップ)、および実際に作業しているマシン (たとえば、1,000 マイル離れた UNIX マシン)。もう 1 つのオプションは、X よりも WAN 経由でうまく機能する VNC のようなものを使用することです。Accurev サーバーの場所にある仮想デスクトップに接続し、そこから X を使用します。私の職場では、Mercurial を副業として使用し、厳密に必要な場合にのみ Accurev に昇格するという手段に頼っているチームが 1 つ以上あります。上記で Stephen Nutt が指摘しているように、他に必要な作業は、タイムスタンプの最適化と無視を使用することです。また、Accurev の管理者 (はい、それを子守するために人を雇う必要があります) は、多数のファイルを含める必要がある場合、それらが製品のコア部分を形成し、含めてバージョン管理する必要があるという事実にもかかわらず、不満を持っています。あなた自身の結論を導き出してください。上記で Stephen Nutt が指摘しているように、他に必要な作業は、タイムスタンプの最適化と無視を使用することです。また、Accurev の管理者 (はい、それを子守するために人を雇う必要があります) は、多数のファイルを含める必要がある場合、それらが製品のコア部分を形成し、含めてバージョン管理する必要があるという事実にもかかわらず、不満を持っています。あなた自身の結論を導き出してください。上記で Stephen Nutt が指摘しているように、他に必要な作業は、タイムスタンプの最適化と無視を使用することです。また、Accurev の管理者 (はい、それを子守するために人を雇う必要があります) は、多数のファイルを含める必要がある場合、それらが製品のコア部分を形成し、含めてバージョン管理する必要があるという事実にもかかわらず、不満を持っています。あなた自身の結論を導き出してください。