當前版本（4.7）Accurev的性能如何？Accurev性能如何？
我剛剛做了一個Accurev的演示，這些流看起來像一個輕量級的方式來圍繞代碼/項目建模工作流。我聽到人們讚揚Accurev的後面，並抱怨表現。 Accurev似乎在表現上有所貢獻，但我想要獲得一些真實世界的數據，以確保它不是演示的樣例 - 運行良好。
有沒有人有Accurev性能軼事或測試數據（甚至更好）？
我沒有任何數字，但我可以告訴你我們在哪裏注意到性能問題。
我們的版本通常使用來自源代碼控制的30-40K文件。在我的工作空間中，目前有超過66K的文件，包括構建中間文件和輸出文件，超過15GB的大小。爲保持AccuRev的響應性，我們積極使用忽略元素，因此AccuRev忽略任何中間文件，如* .obj。另外我們使用時間戳優化。通常運行更新很快，但項目大小通常爲5-10人，所以如果每天更新，通常只有幾十個文件會下降。即使有人做出改變，觸及大量文件，速度也不是問題。另一方面，所有30K +文件的完整填充速度很慢。我沒有時間，因爲我很少這樣做，在我很少的情況下，當我要去吃午餐或開會時，我會跑步。我預計它可能會長達10分鐘。一般來說，源文件很快就會下降，但我們有一些大的二進制文件，10-20MB，每個文件需要幾秒鐘。
如果排除規則和忽略元素未正確配置，AccuRev可能需要幾分鐘的時間才能爲此大小的工作區運行更新。當我聽說其他開發者抱怨速度的時候，我知道某些東西是未配置的，我們將它理順了。
大約一年前，項目中有一個更新了25K +文件，並且還將FireFox添加到了存儲庫中（忘記了大小，但是使得boost看起來很小）。他們還添加了ICU，編寫了大量軟件並修改了無數文件。據我所知，大約有25萬個文件正在流中。我不幸地決定，他們所有的好代碼應該被提升到根目錄，這樣所有的項目都可以共享。事實證明，AccuRev能夠處理得不錯。這是一個多小時的過程，促進所有的變化。據我記得，一旦FireFox被推廣，其餘的進展順利 - 可能是單個交易超過10萬個文件的問題？
我最近更新了boost，所以不得不保持和推廣25K +文件。考慮到文件的數量和二進制文件的大小，花了一兩分鐘的時間，但並非不合理。
至於流的數量，我們有超過800個流和工作區。這裏的性能不是問題。一般情況下，我發現大量的流很難導航，所以我運行一個過濾的視圖，只是我的工作區和我感興趣的正確流。但是，當我需要查看未過濾的列表以查找某些性能是否正常時。
最後一點，AccuRev支持是了不起 - 我們稱他們爲天空中的聲音。我們每時每刻都在使用AccuRev拍攝自己的腳，並且無法解決如何解決問題。幾乎總是我們做了一些愚蠢的事情，然後嘗試了一些麻煩來解決它。最終，我們發出了支持請求，接下來我們知道他們正在通過電話或goto會議的正義步驟走過我們。我甚至與他們聯繫了一些微不足道的事情，我沒有時間弄清楚，因爲我正忙着忙碌的一天，他們好心地走過我，而不是告訴我RTFM。
有點偏離主題，但現在是否可以直接在用戶界面中排除特定的文件和文件夾，以便AccuRev忽略這些文件（如obj等）？上一次我使用AccuRev（2008年中）時，我必須設置一個全局環境變量，其中列出了所有我想讓AccuRev忽略的文件，這很痛苦。 – Nitramk 2009-11-24 09:54:12
我們正在使用4.7，並且你仍然需要設置一個環境變量。有一個更新版本可用，我們尚未升級到所以它可能已經改變，但我懷疑不是。 – 2009-11-24 13:24:47
你可以使用每個目錄的.acignore文件，至少他們隨代碼一起旅行，但吸不是遞歸的。 – 2010-05-25 06:13:27
編輯2014：我們現在可以通過使用商業版本的RealVNC獲得可接受的X-Windows性能。
原創評論：此答案適用於Accurev的任何版本，不只是4.7。首先，如果您可以使用Web客戶端，GUI性能可能會好。如果您不能使用Web客戶端，並且您想要GUI性能，那麼您最好使用Windows，或將所有開發人員放在一個位置，即Accurev服務器所在的位置。嘗試通過WAN在X-Windows上運行GUI？忘記它吧：我們的基本點和點擊操作經驗已經有幾十秒或幾十分鐘了。這是距離800英里遠的一個相當不錯的廣域網，具有幾乎最佳的ping時間。這不是Accurev的失敗，而是X-Windows的失敗，並且您可能在WAN上與其他X應用程序有類似的問題。所以如果可能的話，避免使用基本的X.目前我們不能，而我們的WAN用戶只能被強制降級到命令行。基本問題是Accurev是集中的，你不能提高光速。我相信你可以通過運行Accurev Replication Server解決廣域網延遲問題，但是如果在VPN上有單人辦公室的遠程開發人員，那麼仍然無法正確解決問題。具有諷刺意味的是，複製服務器稍微將此中央VCS轉換爲DVCS形式。如果你沒有複製服務器，那麼一個可怕的，但有點可行的解決方法是使用rsync等增量同步工具來同步你的本地機器之間的源代碼樹，你可以在其中運行GUI（即GUI直接運行在你的Windows或Linux筆記本電腦）和實際工作的機器（例如1000英里外的UNIX機器）。另一種選擇是使用像VNC這樣的比WAN更適合在WAN上工作的東西，在Accurev服務器的位置連接到虛擬桌面，然後從那裏使用X.在我的工作場所，不止一個團隊使用了Mercurial，並且只有在嚴格需要時才向Accurev推廣。正如斯蒂芬納特指出的那樣，其他必要的工作是使用時間戳優化並忽略。我們也有我們的Accurev管理員（是的，它需要僱用人才能讓孩子坐在這裏）投訴，當我們需要包含大量文件時，儘管它們構成了我們產品的核心部分，並且必須包含在內並受版本控制。畫出自己的結論。
軼事答案：慢。除非必須使用，否則請勿使用。 GUI幾乎不可用。這只是一個軼事，我沒有任何必要的數字來支持我說的話。 – Martin 2015-02-05 14:54:16
我剛剛將一個Perforce項目遷移到最新的Accurev 6.2.3？，並且我聽到的很多恐怖故事還沒有以我能說的任何方式表現出來，但是GUI非常慢，我不知道不建議在離線時做任何動作。我喜歡這一點，我不需要檢查一下，但是有一個性能成本。最大的問題是與GUI相比，包括點擊一個文件在內的GUI中的任何操作都需要很長時間。我建議學習CLI。 – Novaterata 2016-11-17 21:11:01