### Subversion和DeltaV 所以Subversion與其他DeltaV的兼容性如何？兩個字：不好，至少在Subversion 1.0還不好。 當libsvn_ra_dav發送DeltaV到服務器，Subversion客戶端*不是*一個普通目的的DeltaV客戶端。實際上，它希望服務器一些自定義的特性（特別是通過自定義的`REPORT`請求）。更進一步，mod_dav_svn*不是*一個普通目的的DeltaV服務器，它只實現了DeltaV的一個嚴格子集，一個更加普通的WebDAV或DeltaV客戶端可能與之很好的交互工作，但是只有在服務器非常窄的已經實現的特性范圍之內。Subversion開發團隊計劃會設法在以后的版本中完成普通的WebDAV交互性。 ### 影射Subversion到DeltaV 這里是多種Subversion客戶端如何使用DeltaV操作的一個非常“高級別”描述。在很多種情況下，這些解釋過于粗略，這*不*能作為閱讀Subversion源代碼和與開發者交談的替代。 svn checkout/list 對集合執行一個深度為1的`PROPFIND`來得到直接孩子的列表，對每個孩子執行一個`GET`（也可能是一個`PROPFIND`），遞歸到集合并且重復。 svn commit 使用`MKACTIVITY`創建一個活動，然后對每個修改項目執行一個`CHECKOUT`，緊跟一個對新數據的`PUT`。最終，一個`MERGE`請求導致一個隱含的對所有工作資源的`CHECKIN`。 svn update/switch/status/merge/diff 發送一個自定義的描述工作拷貝混合修訂版本（和混合URL）狀態的`REPORT`請求，服務器發送一個描述需要更新的項目和文件內容增量數據的響應。解析響應，對于update和switch，在工作拷貝安裝新數據，對于diff和merge，與工作拷貝的數據比較，應用修改作為本地修改。 ### 自動版本化支持 在寫作的時候，有一個事實就是這個世界只有很少的DeltaV客戶端；RFC 3253一直是相對比較新。然而用戶有一些“普通的”客戶端，因為幾乎所有的現代操作系統現在擁有集成的基本WebDAV客戶端，因為這一點，Subversion開發者認識到如果Subversion 1.0可以支持DeltaV自動版本化這一交互特性會是最好的方法。 為了激活mod_dav_svn的自動版本化，使用`httpd.conf``Location`區塊的`SVNAutoversioning`指示，例如： ~~~ <Location /repos> DAV svn SVNPath /absolute/path/to/repository SVNAutoversioning on </Location> ~~~ 通常情況下，如果一個原始的WebDAV客戶端嘗試`PUT`到你的版本庫位置的一個路徑，mod_dav_svn會直接拒絕這個請求。（通常只允許對于DeltaV“活動”里面的對于“工作資源”的操作。）通過打開`SVNAutoversioning`，無論何時，服務器會把`PUT`請求轉化為內部的`MKACTIVITY`、`CHECKOUT`、`PUT`和`CHECKIN`。一個普通的日志信息是自動生成的，并且創建一個新的文件系統修訂版本。 因為有這樣多的操作系統已經集成了WebDAV能力，這個特性的用例近似于空想：想象一個普通用戶運行Microsoft Windows或Mac OS的辦公室，每個電腦“裝配”了一個Subversion版本庫，作為一個普通的網絡共享。他們向普通目錄一樣操作服務器：從服務器打開文件，修改并且保存回服務器。但在這個幻想中，服務器自動版本化所有的事情，之后，一個系統管理員可以使用Subversion客戶端來查找和檢索所有舊的版本。 這個幻想是現實嗎？完全不是，主要的障礙是Subversion 1.0不支持WebDAV的`LOCK`方法`UNLOCK`，大多數操作系統的DAV客戶端嘗試`LOCK`一個直接從DAV裝配的網絡共享的資源，到目前為止，用戶必須要把文件從DAV共享拷貝到本地磁盤，編輯文件，然后再拷貝回去。沒有理想的自動版本化，但還是可行的。 ### 選擇mod_dav_lock Apache模塊mod_dav是一個復雜的野獸：它理解和解析所有的WebDAV和DeltaV方法，然而它依賴于后端“提供者”來訪問資源本身。 在最簡單的化身里，一個用戶可以使用mod_dav_fs可以作為mod_dav的提供者，mod_dav_fs使用普通的文件系統來存放文件和目錄，只理解平凡的WebDAV方法，不是DeltaV。 在另一方面，Subversion使用mod_dav_svn作為mod_dav的提供者，mod_dav_svn理解除了`LOCK`以外的所有WebDAV方法，并且理解相當大的DeltaV方法子集，它訪問Subversion版本庫的數據，而不是真實的文件系統。Subversion 1.0不支持鎖定，因為這會非常難于實現，因為Subversion使用拷貝-修改-合并模型。 在Apache httpd-2.0里，mod_dav可以通過追蹤私有數據庫的鎖來支持`LOCK`方法，假定提供者會樂于接受這一點。在Apache httpd-2.1或以后的版本，這個鎖定支持會拆到一個獨立的模塊，mod_dav_lock。它允許任何mod_dav提供者利用鎖數據庫的好處，包括mod_dav_svn，即使mod_dav_svn實際上不理解鎖定。 感到困惑？ 簡言之，你可以使用Apache httpd-2.1（或更晚的）的mod_dav_lock來創建一個錯覺，也就是mod_dav_svn負責了`LOCK`操作。確定mod_dav_lock已經編譯到httpd或已經在`httpd.conf`中加載，然后只需要在`Location`簡單的添加如下的`DAVGenericLockDB`指示： ~~~ <Location /repos> DAV svn SVNPath /absolute/path/to/repository SVNAutoversioning on DavGenericLockDB /path/to/store/locks </Location> ~~~ 這個技術是一個有危險的業務；在一些情況，mod_dav_svn現在已經接近WebDAV客戶端，它宣稱接受`LOCK`請求，但是實際上鎖并不是在所有的級別上強制執行。如果第二個WebDAV客戶端嘗試`LOCK`鎖住同樣的資源，然后mod_dav_lock會注意到并且正確的拒絕這個請求，但是完全沒有辦法來防止一個普通的Subversion客戶端使用**svn commit**來修改文件！如果你使用這個技術，你給用戶權利來踐踏其他人的修改，更具體一點，一個WebDAV客戶端會不小心覆蓋普通Subversion客戶端提交的修改。 在另一方面，如果你小心設置你的環境變量，你會減輕這個風險，例如，如果*所有*用戶使用WebDAV客戶端（而不是Subversion客戶端），然后事情變得美好了。 Subversion可能有一天會開發一個保留檢出的鎖定模型，可以與拷貝-修改-合并和平相處，但是可能不會立刻發生。