最近推出的新版本控制系統 Evo 承諾簡化程式碼管理，但這引發了開發者們的廣泛討論，他們質疑其基於工作區的方法是否真能解決現實世界的開發挑戰。
工作區模型面臨實踐性問題
雖然 Evo 推廣以工作區為基礎的特性開發流程，作為 Git 分支系統的替代方案，但經驗豐富的開發者對其實用性提出了擔憂。其提出的線性工作流程（開發者為每個特性建立工作區、完成工作併合並）似乎過度簡化了軟體開發的複雜性。許多開發者指出，現實世界的開發很少遵循如此直接的路徑，工作通常涉及多個相互關聯的變更和並行開發流程。
「我對任何假設每個特性只需要一個分支/工作區的方案都持懷疑態度。在我的職業生涯中從未這樣工作過。我總是在同時處理一系列需要被分別審查和合並的變更。」
社群關注問題：
- 線性工作流程的侷限性
- 命令的清晰度和文件說明
- 複雜合併場景的處理
- 功能隔離與並行開發的平衡
- 與實際工作流程的相容性
歷史背景和技術挑戰
這場討論引發了與之前版本控制系統的有趣對比，特別是與採用補丁管理方法而非專注於修訂歷史的 Darcs 系統的比較。社群爭論突顯了版本控制系統設計中的一個基本矛盾：是優先考慮管理補丁（特性）還是修訂版本。這場討論表明兩種方法都有其優勢和侷限性，一些開發者指出理想的解決方案可能需要有效地結合這兩種正規化。
技術文件和清晰度問題
開發者們還對 Evo 命令和文件的清晰度提出了質疑。與更直接的 Git 命令（如 push ）相比，evo workspace merge 命令被批評含義模糊。這凸顯了一個更廣泛的問題：簡化版本控制是否必然導致更好的可用性，特別是當底層概念仍然複雜的情況下。
Evo 的主要特性：
- 基於工作空間的開發模式
- 內建大檔案支援
- 針對 JSON 和 YAML 檔案的結構化合並
- 離線優先架構
- 基於 Ed25519 的提交簽名
- HTTP/2 客戶端-伺服器通訊
企業級功能受到審視
雖然 Evo 宣稱具有內建的大檔案支援和配置檔案的結構化合並功能，但社群要求提供更詳細的資訊，說明這些功能在實踐中如何運作。特別是，開發者們希望看到系統如何處理多個特性合併時的衝突，以及如何管理從文字程式碼到大型媒體資產等不同型別的檔案。
開發社群的懷疑態度表明，雖然改進版本控制工具的需求確實存在，但任何新的解決方案都需要充分應對現代軟體開發的複雜現實，而不是僅僅簡化介面。
參考連結：Evo：版本控制的演進