加強 Subversion 伺服器

本文經許可從原始位置 https://www.open.collab.net/community/subversion/articles/EnhancingSubversionServer.html 複製。已移除或更新失效連結。資訊截至 Subversion 1.4 為止，有些部分可能不適用於目前版本。

在為許多相關專案管理 Subversion 伺服器時，在開放原始碼社群或企業中，需要在標準化開發環境和提供個別團隊足夠彈性以各種方式工作之間取得有用的平衡，以利有效合作。個人和專案會定期要求特定功能或自訂。本文討論何時自訂、如何自訂，並建議對此類要求採取建議的方法。

第一個也是最重要的問題是何時要自訂。許多軟體工程師和專案都有自然傾向去調整或自訂他們的工具和環境，以符合他們的喜好、厭惡和需求。他們通常對特定的自訂感到強烈，並推動這些自訂，而不一定適當地考慮或量化對他們自己、他們的專案，或組織或整體社群的成本。只要自訂只影響個人，你就可以辯稱那只是一個人的問題和責任。然而，當它影響到多個人、一個專案或整個組織時，你必須平衡成本和效益。

自訂的成本 ¶

顯而易見的成本是建立和維護自訂所需的努力量。它必須在環境演進時撰寫、測試和維護。此外，自訂會增加存取資料的門檻：自訂會改變工具和實務的行為以及工具的使用，實際上讓局外人更難理解、參與和貢獻專案。此外，如果使用者對自訂有問題，則需要支援每個自訂。換句話說，每個自訂都會讓伺服器操作和維護的成本更高，增加使用者協作的門檻，並增加需要支援的功能種類。

因此，絕大多數專案都必須有具體效益，或少數專案有顯著效益。請注意，前者可以說不是自訂，而更像是使用者想要的某項功能的要求（和早期原型）。後者可以說是一種對大多數使用者來說太過特定的自訂。

如何自訂 ¶

有各種方式可以擴充 Subversion 已提供的功能。這些選項可以分類為兩種：用戶端或伺服器端自訂。

用戶端 - 封裝程式 ¶

用戶端自訂是伺服器不變更，而自訂在用戶端透過包裝命令列用戶端或用戶端 API 呼叫來完成的解決方案。用戶端自訂讓自訂的負擔落在提出要求的個人或專案，並強迫請求者進行適當、誠實的成本效益分析，以判斷是否真的想要或需要自訂。此外，包裝器在可處理的自訂數量方面擴充性很好：維護包裝器的人數會隨著自訂而擴充。

用戶端自訂的範例是 svnmerge.py，一個建立在標準 Subversion 命令列用戶端上的 Python 腳本，可讓使用者輕鬆地合併來自分支或合併到分支的變更，並自動記錄哪些變更組已合併。它可以顯示尚未合併的變更的最新清單，並防止合併錯誤，例如兩次合併相同的變更。svnmerge.py 腳本基本上是合併追蹤功能的早期原型，目前正針對 Subversion 的未來版本進行討論、設計和實作。

伺服器端 - 掛勾腳本 ¶

伺服器端自訂是伺服器組態變更的解決方案。伺服器端自訂在將自訂推展到伺服器上所有專案方面擴充。它們會影響網站的日常操作，並增加營運服務的成本和工作。此外，它們可能會影響服務的安全性、可用性和效能。

伺服器端自訂功能的主要範例是掛勾指令碼。掛勾，或掛勾指令碼，是一個由某些儲存庫事件觸發的程式，例如建立新的修訂版本或修改未版本化的屬性。每個掛勾都會收到足夠的資訊，以說明該事件是什麼、它在哪些目標上執行，以及觸發該事件的使用者名稱。根據掛勾的輸出或傳回狀態，掛勾程式可能會繼續執行動作、停止動作或以某種方式暫停動作。Subversion 版本控制手冊更詳細地說明了這一點。

Subversion 目前定義了九個掛勾

start-commit 掛勾在執行提交的過程中建立交易之前呼叫。
pre-commit 掛勾在建立交易之後但在提交之前呼叫。
post-commit 掛勾在提交交易之後呼叫。
pre-revprop-change 和 post-revprop-change 掛勾分別在新增、修改或刪除修訂版本屬性之前和之後呼叫。
pre-lock 和 post-lock 掛勾分別在建立路徑的獨佔鎖定之前和之後呼叫。
pre-unlock 和 post-unlock 掛勾分別在銷毀獨佔鎖定之前和之後呼叫。

掛勾通常用於三種類型的功能

首先，記錄或通知相關人員有關事件。例如，針對每次提交傳送電子郵件訊息，摘要說明該提交的主要資訊，例如作者、日期、提交訊息和變更集。
其次，檢查特定條件。例如，驗證程式碼是否符合編碼指南，或使用者是否有權存取他想要提交至儲存庫的部分。
第三，封鎖特定行為。例如，允許使用者變更記錄訊息，但不得變更修訂的作者和日期（以維持可追蹤性），防止鎖定被竊取，或僅在路徑設定 svn:needs-lock 屬性的情況下允許鎖定。

請注意，目前 Subversion 不支援執行前處理或後處理功能的掛勾，例如自動確保程式碼符合編碼指南，因為伺服器沒有辦法將此類變更傳達回用戶端。換句話說，掛勾所做的任何事都不會修改交易本身。相反地，它可以檢查條件並接受或拒絕動作。

掛勾基本上是一種在伺服器上執行任意程式碼的方法，以回應版本控制用戶端所執行的動作。此外，掛勾會以與一般網路伺服器相同的權限執行，因此有能力影響同一伺服器上的其他儲存庫。這個機制非常強大，但可能會對伺服器的安全性、可用性和效能造成影響。掛勾很容易讓你的伺服器變慢或當機，甚至更糟的是損毀儲存庫中的資料。

發現和建議 ¶

當管理一個 Subversion 伺服器用於多個專案時，您需要在標準化環境以利於有效協作和高效運作之間取得有用的平衡，同時讓專案有足夠的彈性以各種方式運作。標準化可以帶來許多好處，例如在切換專案時減少學習環境的時間，並使團隊之間的協作更有效率。然而，一體適用的方式在個人和專案團隊中今日的異質性（在地方文化、部門文化、流程等方面）中既不可行也不可取。

從技術角度來看，用戶端和伺服器端的自訂在它們能做和不能做的事情上有所不同

用戶端自訂適用於僅影響單一使用者或自動預處理（例如程式碼格式化）的情況。
伺服器端自訂適用於變更應在儲存庫中標準化且為通知、檢查或封鎖特定行為的情況。

從成本效益的角度來看，請嘗試將僅特定於有限使用者群組的自訂保留在用戶端。這將自訂的負擔加諸於專案上，刺激他們進行適當且誠實的成本效益分析，並防止其影響他人。與大量專案相關且由其要求的通用自訂更適合於伺服器端。伺服器端自訂通常有大幅更高的成本，主要是因為它們可能會影響整個伺服器的效能、可用性和安全性。它們需要嚴格的測試，無論是在建立時或每次伺服器升級時。

特別是在部署掛勾時，我們強烈建議僅使用非常常用的掛勾，以減輕風險（掛勾使用得越多，測試就越多）並在標準化和自訂化之間取得合理的平衡：掛勾只有在為許多人帶來價值時才會流行，並且值得付出努力。要求深奧的自訂化可能不值得花費精力去建立、測試和維護。