許多(duō)企業會選擇使用(yòng) Subversion 的(de)原因是：因為它是免費的(de)；但是當您使用(yòng)一段時間後，就能漸漸瞭解到使用(yòng) SVN 的(de)真正成本。雖然無須付費取得(de) SVN 授權使用(yòng)，但為了(le)要維持其運作，反而可(kě)能損耗公司更多(duō)的(de)資源。
檔案管理(lǐ)問題層出不窮，欠佳的(de)工作流程、糟糕的(de)擴充性，和(hé)過時的(de)功能；這些缺陷都會導緻生產力下(xià)滑。在多(duō)數情況下(xià)，產能上的(de)損失，遠比採用(yòng)專利版本控制系統來得(de)昂貴。
針對這些，使用(yòng) Subversion 而喪失生產力的(de)團隊，Perforce 的(de) HelixCore 提供了(le)一個令人(rén)驚豔的(de)解決方案。請您繼續往下(xià)閱讀以瞭解，為何優秀團隊多(duō)偏好 Perforce Helix Core 的(de) 9 個理(lǐ)由。
1. SVN 沒有程式碼審查功能
SVN 未內建程式碼審查功能。想要進行程式碼審查，必須取得(de)第三方產品的(de)授權。Helix Core 內含 Helix Swarm，是企業級的(de)程式碼審查解決方案。Helix Swarm 可(kě)與您的(de) CI 工作流程輕鬆整合。
2. SVN 隻有基本合併功能
SVN 隻有進行基本合併的(de)能力，而且基準線的(de)選擇有所限制；所以經常導緻耗時費力的(de)合併衝突。兩相比較之下(xià)，Helix Core 可(kě)跨越分(fēn)支，自動追蹤所有合併的(de)歷史記錄；甚至包括檔案的(de)更名與移動，都能夠追蹤記錄。
3. SVN 的(de)發行管理(lǐ)複雜且容易出錯
SVN 中，使用(yòng)者必須透過命名規則來辨認分(fēn)支。如果發現有變更必需整進數個開發分(fēn)支時，合併回主線的(de)工作，將會變得(de)十分(fēn)複雜，而且容易出錯。合併困難是SVN使用(yòng)者之間，最廣泛討論的(de)主題之一；其貧弱的(de)分(fēn)支功能正是根本原因。
Helix Core 創建了(le)名為「 Streams 」的(de)分(fēn)支結構。Streams 將分(fēn)支分(fēn)類為主線、開發支線及發行支線，並自動辨識哪些變更需要進行散佈，以及應該散佈至哪些Streams。這樣的(de)功能，讓合併分(fēn)支的(de)工作，立馬變得(de)輕而易舉。如果將 SVN 的(de)分(fēn)支功能和(hé) Helix Core 的(de) Streams 拿來作比較，應該很容易就能瞭解，為什(shén)麼這麼多(duō)團隊，最終都選擇了(le) Perforce。
4. SVN 效能有限和(hé)擴充性也(yě)有限
SVN 為單一伺服器系統，嚴重地限制了(le)其效能和(hé)擴充性；因此 SVN 並不擅於處理(lǐ)大(dà)型資料庫和(hé)檔案。一般來說，其上限約為 250 名使用(yòng)者，與 1TB 的(de)檔案容量。
Helix Core 有很多(duō)客戶，使用(yòng)者都超過一萬名以上；他(tā)們儲存在主伺服器上的(de)資料量，都是以 petabyte 為單位來計算(suàn)的(de)。
5. SVN 無法管理(lǐ) Git Repos
SVN 沒有 Git 管理(lǐ)功能。團隊如果想要管理(lǐ) Git，Helix4Git 是 Perforce 提供的(de)選項；讓您能夠直接在，高(gāo)效能的(de) Helix Core 伺服器上，儲存 Git 資料庫。透過 Helix4Git，團隊可(kě)以提升 Git 協作效率，並使程式建構速度提高(gāo) 80%。
6. SVN 不易離線使用(yòng)
雖然 SVN 允許離線工作，但卻需要相當的(de)計畫與協調。您必須先將整個資料庫複製一份，然後放在本地端的(de) SVN 伺服器上執行。期間要是有任何人(rén)變更了(le)任何檔案的(de)路徑，您將會無法將您的(de)檔案傳回原始資料庫。
透過 Helix Core，您可(kě)於本地端工作區內離線作業；待重新連線後，隻需一個指令就能整合所有變更。對需要離線作業的(de)團隊來說，選擇 Perforce 的(de)原因也(yě)就更加顯而易見了(le)。
7. SVN 找尋檔案歷史相當耗時
使用(yòng) SVN 來尋找變更─不論要找的(de)是特定使用(yòng)者所做(zuò)的(de)變更，或是被刪除檔案的(de)位置─簡單的(de)報告也(yě)要花上數分(fēn)鐘。速度這麼慢(màn)的(de)原因是：SVN 必需先列出專案完整的(de)歷史記錄，然後再加以過濾，最後才能輸出結果。
Helix Core 不但有完整的(de)指令集，也(yě)有完善的(de)圖形化(huà)介面 Helix Visual Client (P4V)，都能生成檔案歷史報告。透過 TimeLapse View, Revision Graph 和(hé) Folder Diff 等先進功能，您隨時都能掌握資源的(de)完整追溯性，與所有變更的(de)履歷。
8. SVN 欠缺開箱即用(yòng)的(de)安全功能
SVN 提供了(le)以資料庫，以及以路徑為準的(de)，最基本的(de)存取控制；然而一旦上線後，便難以管理(lǐ)。在這個時代，您所需要的(de)遠超於此。
Helix Core 擁有強大(dà)的(de)檔案層級存取控制與稽核機制，同時支援 SSO 與全方位多(duō)重要素驗證（或 MFA）保護機制；是當今市場上最安全的(de)版本控制系統。就安全性而言，在 Perforce 與 Subversion 的(de)競賽中，Helix Core 似乎是顯而易見的(de)贏家。
9. SVN 無法支援跨國團隊
SVN 缺乏像是資料快(kuài)取、副本伺服器等，能夠支援全球化(huà)工作團隊的(de)先進技術。所以團隊將受限於廣域網路的(de)傳輸能力。
相較之下(xià)，Helix Core 擁有獨步全球的(de)創新技術─其中包含資料快(kuài)取，以及名為「聯合架構(federated architecture)」的(de)先進副本伺服器技術。透過聯合架構，跨國團隊也(yě)可(kě)以用(yòng) LAN 一般的(de)速度，來存取與管理(lǐ)所有檔案資料。
Perforce 對 SVN 的(de)決戰，何者勝出？
大(dà)多(duō)數開源產品都有一些嚴重的(de)隱性成本：降低生產力、開發不斷延遲，以及高(gāo)維護費用(yòng)。這些隱性成本通(tōng)常會比使用(yòng)者授權費用(yòng)，來得(de)更為昂貴。
所以 Perforce 與 SVN 的(de)對決中，到底誰會勝出？針對那些，因為使用(yòng)Subversion 而喪失生產力的(de)團隊，Perforce 提供了(le)一個令眾人(rén)折服的(de)解決方案：Helix Core；一個歷經千錘百鍊的(de)整合式平台，並且針對 Agile 和(hé) DevOps 進行了(le)深度的(de)優化(huà)。
歡迎關注 Graser 社群，即時掌握最新技術應用(yòng)資訊
