Apache的HTTP伺服器是一個Subversion可以利用的「重型」網路伺服器，通過一個自行定義模塊，httpd可以讓Subversion版本庫通過WebDAV/DeltaV協議在客戶端前可見，WebDAV/DeltaV協議是HTTP 1.1的擴展(見http://www.webdav.org/來查看詳細訊息)。這個協議利用了無處不在的HTTP協議是廣域網的核心這一點，新增了寫能力—更明確一點，版本化的寫—能力。結果就是這樣一個標準化的健壯的系統，作為Apache 2.0軟體的一部分打包，被許多操作系統和第三方產品支持，網路管理員也不需要打開另一個自行定義埠號。 [40]這樣一個Apache-Subversion伺服器具備了許多svnserve沒有的特性，但是也有一點難於設定，靈活通常會帶來複雜性。
下面的討論包括了對Apache設定指示的引用，給了一些使用這些指示的例子，詳細地描述不在本章的範圍之內，Apache小組維護了完美的文件，公開存放在他們的站點http://httpd.apache.org。例如，一個一般的設定參考位於 http://httpd.apache.org/docs-2.0/mod/directives.html。
同樣，當你修改你的Apache設定，很有可能會出現一些錯誤，如果你還不熟悉Apache的日誌子系統，你一定需要認識到這一點。在你的文件httpd.conf裡會指定Apache生成的訪問和錯誤日誌(CustomLog和ErrorLog指示)的磁碟位置。Subversion的mod_dav_svn使用Apache的錯誤日誌介面，你可以瀏覽這個文件的內容查看訊息來查找難於發現的問題根源。
為了讓你的版本庫使用HTTP網路，你基本上需要兩個包裡的四個部分。你需要Apache httpd2.0和包括的mod_dav DAV模塊，Subversion和與之一同分發的mod_dav_svn文件系統提供者模塊，如果你有了這些組件，網路化你的版本庫將非常簡單，如：
設定好httpd 2.0，並且使用mod_dav啟動，
為mod_dav安裝mod_dav_svn外掛，它會使用Subversion的庫訪問版本庫，並且
設定你的httpd.conf來輸出(或者說暴露)版本庫。
你可以通過從原始碼編譯httpd和Subversion來完成前兩個項目，也可以通過你的系統上的已經編譯好的二進制包來安裝。最新的使用Apache HTTP的Subversion的編譯方法和Apache的設定方式可以看Subversion原始碼樹根目錄的INSTALL文件。
一旦你安裝了必須的組件，剩下的工作就是在httpd.conf裡設定Apache，使用LoadModule來加載mod_dav_svn模塊，這個指示必須先與其它Subversion相關的其它設定出現，如果你的Apache使用預設部署安裝，你的mod_dav_svn模塊一定在Apache安裝目錄(通常是在/usr/local/apache2)的modules子目錄，LoadModule指示的語法很簡單，影射一個名字到它的共享庫的物理位置：
LoadModule dav_svn_module modules/mod_dav_svn.so
注意，如果mod_dav是作為共享對像編譯(而不是靜態鏈接到httpd程序)，你需要為它使用LoadModule語句，一定確定它在mod_dav_svn之前：
LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so
在你的設定文件後面的位置，你需要告訴Apache你在什麼地方保存Subversion版本庫(也許是多個)，位置指示有一個很像XML的符號，開始於一個開始標籤，以一個結束標籤結束，配合中間許多的其它設定。Location指示的目的是告訴Apache在特定的URL以及子URL下需要特殊的處理，如果是為Subversion準備的，你希望可以通過告訴Apache特定URL是指向版本化的資源，從而把支持轉交給DAV層，你可以告訴Apache將所有路徑部分(URL中伺服器名稱和埠號之後的部分)以/repos/開頭的URL交由DAV服務提供者處理。一個DAV服務提供者的版本庫位於/absolute/path/to/repository，可以使用如下的httpd.conf語法：
<Location /repos> DAV svn SVNPath /absolute/path/to/repository </Location>
如果你計劃支持多個具備相同父目錄的Subversion版本庫，你有另外的選擇，SVNParentPath指示，來表示共同的父目錄。舉個例子，如果你知道會在/usr/local/svn下建立多個Subversion版本庫，並且通過類似http://my.server.com/svn/repos1，http://my.server.com/svn/repos2的URL訪問，你可以用後面例子中的httpd.conf設定語法：
<Location /svn> DAV svn # any "/svn/foo" URL will map to a repository /usr/local/svn/foo SVNParentPath /usr/local/svn </Location>
使用上面的語法，Apache會代理所有URL路徑部分為/svn/的請求到Subversion的DAV提供者，Subversion會認為SVNParentPath指定的目錄下的所有項目是真實的Subversion版本庫，這通常是一個便利的語法，不像是用SVNPath指示，我們在此不必為建立新的版本庫而重啟Apache。
請確定當你定義新的Location，不會與其它輸出的位置重疊。例如你的主要DocumentRoot是/www，不要把Subversion版本庫輸出到<Location /www/repos>，如果一個請求的URI是/www/repos/foo.c，Apache不知道是直接到repos/foo.c訪問這個文件還是讓mod_dav_svn代理從Subversion版本庫返回foo.c。伺服器返回的結果通常是301 Moved Permanently。
在本階段，你一定要考慮訪問權限問題，如果你已經作為普通的web伺服器運行過Apache，你一定有了一些內容—網頁、腳本和其他。這些項目已經設定了許多在Apache下可以工作的訪問許可，或者更準確一點，允許Apache與這些文件一起工作。Apache當作為Subversion伺服器運行時，同樣需要正確的訪問許可來讀寫你的Subversion版本庫。
你會需要檢驗權限系統的設定滿足Subversion的需求，同時不會把以前的頁面和腳本搞亂。這或許意味著修改Subversion的訪問許可來配合Apache伺服器已經使用的工具，或者可能意味著需要使用httpd.conf的User和Group指示來指定Apache作為運行的用戶和Subversion版本庫的組。並不是只有一條正確的方式來設定許可，每個管理員都有不同的原因來以特定的方式操作，只需要意識到許可關聯的問題經常在為Apache設定Subversion版本庫的過程中被疏忽。
此時，如果你設定的httpd.conf保存如下的內容
<Location /svn> DAV svn SVNParentPath /usr/local/svn </Location>
…這樣你的版本庫對全世界是可以「匿名」訪問的，直到你設定了一些認證授權政策，你通過Location指示來使Subversion版本庫可以被任何人訪問，換句話說，
任何人可以使用Subversion客戶端來從版本庫URL取出一個工作副本(或者是它的子目錄)，
任何人可以在瀏覽器輸入版本庫URL交互瀏覽的方式來查看版本庫的最新修訂版本，並且
任何人可以提交到版本庫。
當然，你也許已經設定了pre-commit鉤子來防止提交(見「實現版本庫鉤子」一節)，但是就像你讀到的，也可以使用Apache內建的方法來限制訪問。
最簡單的客戶端認證方式是通過HTTP基本認證機制，簡單的使用用戶名和密碼來驗證一個用戶所自稱的身份，Apache提供了一個htpasswd工具來管理可接受的用戶名和密碼，這些就是你希望賦予Subversion特別權限的用戶，讓我們給Sally和Harry賦予提交權限，首先，我們需要新增他們到密碼文件。
$ ### First time: use -c to create the file $ ### Use -m to use MD5 encryption of the password, which is more secure $ htpasswd -cm /etc/svn-auth-file harry New password: ***** Re-type new password: ***** Adding password for user harry $ htpasswd -m /etc/svn-auth-file sally New password: ******* Re-type new password: ******* Adding password for user sally $
下一步，你需要在httpd.conf的Location區裡新增一些指示來告訴Apache如何來使用這些密碼文件，AuthType指示指定系統使用的認證類型，這種情況下，我們需要指定Basic認證系統，AuthName是你提供給認證域一個任意名稱，大多數瀏覽器會在向用戶詢問名稱和密碼的彈出窗口裡顯示這個名稱，最終，使用AuthUserFile指示來指定使用htpasswd建立的密碼文件的位置。
新增完這三個指示，你的<Location>區塊一定像這個樣子：
<Location /svn> DAV svn SVNParentPath /usr/local/svn AuthType Basic AuthName "Subversion repository" AuthUserFile /etc/svn-auth-file </Location>
這個<Location>區塊還沒有結束，還不能做任何有用的事情，它只是告訴Apache當需要授權時，要去向Subversion客戶端索要用戶名和密碼。我們這裡遺漏的，是一些告訴Apache什麼樣客戶端需要授權的指示。哪裡需要授權，Apache就會在哪裡要求認證，最簡單的方式是保護所有的請求，新增Require valid-user來告訴Apache任何請求需要認證的用戶：
<Location /svn> DAV svn SVNParentPath /usr/local/svn AuthType Basic AuthName "Subversion repository" AuthUserFile /etc/svn-auth-file Require valid-user </Location>
一定要閱讀後面的部分(「授權選項」一節)來得到Require的細節，和授權政策的其他設定方法。
需要警惕：HTTP基本認證的密碼是用明文傳輸，因此非常不可靠的，如果你擔心密碼偷窺，最好是使用某種SSL加密，所以客戶端認證使用https://而不是http://，為了方便，你可以設定Apache為自簽名認證。 [41]參考Apache的文件(和OpenSSL文件)來查看怎樣做。
商業應用需要越過公司防火牆的版本庫訪問，防火牆需要小心的考慮非認證用戶「吸取」他們的網路流量的情況，SSL讓那種形式的關注更不容易導致敏感資料洩露。
如果Subversion使用OpenSSL編譯，它就會具備與Subversion伺服器使用https://的URL通訊的能力，Subversion客戶端使用的Neon庫不僅僅可以用來驗證伺服器證書，也可以必要時提供客戶端證書，如果客戶端和伺服器交換了SSL證書並且成功地互相認證，所有剩下的交流都會通過一個會話關鍵字加密。
怎樣產生客戶端和伺服器端證書以及怎樣使用它們已經超出了本書的範圍，許多書籍，包括Apache自己的文件，描述這個任務，現在我們可以覆蓋的是普通的客戶端怎樣來管理伺服器與客戶端證書。
當通過https://與Apache通訊時，一個Subversion客戶端可以接收兩種類型的訊息：
一個伺服器證書
一個客戶端證書的要求
如果客戶端接收了一個伺服器證書，它需要去驗證它是可以相信的：這個伺服器是它自稱的那一個嗎？OpenSSL庫會去檢驗伺服器證書的簽名人或者是核證機構(CA)。如果OpenSSL不可以自動信任這個CA，或者是一些其他的問題(如證書過期或者是主機名不匹配)，Subversion指令列客戶端會詢問你是否願意仍然信任這個證書：
$ svn list https://host.example.com/repos/project Error validating server certificate for 'https://host.example.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: host.example.com - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT - Issuer: CA, example.com, Sometown, California, US - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b (R)eject, accept (t)emporarily or accept (p)ermanently?
這個對話看起來很熟悉，這是你會在web瀏覽器(另一種HTTP客戶端，就像Subversion)經常看到的問題，如果你選擇(p)ermanent選項，伺服器證書會存放在你存放那個用戶名和密碼快取(見「客戶端憑證快取」一節。)的私有運行區auth/中，快取後，Subversion會自動記住在以後的交流中信任這個證書。
你的運行中servers文件也會給你能力可以讓Subversion客戶端自動信任特定的CA，包括全域的或是每主機為基礎的，只需要設定ssl-authority-files為一組逗號隔開的PEM加密的CA證書列表：
[global] ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem
許多OpenSSL安裝包括一些預先定義好的可以普遍信任的「預設的」CA，為了讓Subversion客戶端自動信任這些標準權威，設定ssl-trust-default-ca為true。
當與Apache通話時，Subversion客戶端也會收到一個證書的要求，Apache是詢問客戶端來證明自己的身份：這個客戶端是否是他所說的那一個？如果一切正常，Subversion客戶端會發送回一個通過Apache信任的CA簽名的私有證書，一個客戶端證書通常會以加密方式存放在磁碟，使用本地密碼保護，當Subversion收到這個要求，它會詢問你證書的路徑和保護用的密碼：
$ svn list https://host.example.com/repos/project Authentication realm: https://host.example.com:443 Client certificate filename: /path/to/my/cert.p12 Passphrase for '/path/to/my/cert.p12': ******** …
注意這個客戶端證書是一個「p12」文件，為了讓Subversion使用客戶端證書，它必須是運輸標準的PKCS#12格式，大多數瀏覽器可以匯入和導出這種格式的證書，另一個選擇是用OpenSSL指令列工具來轉換存在的證書為PKCS#12格式。
再次，運行中servers文件允許你為每個主機自動響應這種要求，單個或兩條訊息可以用運行參數來描述：
[groups] examplehost = host.example.com [examplehost] ssl-client-cert-file = /path/to/my/cert.p12 ssl-client-cert-password = somepassword
一旦你設定了ssl-client-cert-file和 ssl-client-cert-password參數，Subversion客戶端可以自動響應客戶端證書請求而不會打擾你。[42]
此刻，你已經設定了認證，但是沒有設定授權，Apache可以要求用戶認證並且確定身份，但是並沒有說明這個身份的怎樣允許和限制，這個部分描述了兩種控制訪問版本庫的策略。
最簡單的訪問控制形式是授權特定用戶為只讀版本庫訪問或者是讀/寫訪問版本庫。
你可以通過在<Location>區塊新增Require valid-user指示來限制所有的版本庫操作，使用我們前面的例子，這意味著只有客戶端只可以是harry或者sally，而且他們必須提供正確的用戶名及對應密碼，這樣允許對Subversion版本庫做任何事：
<Location /svn> DAV svn SVNParentPath /usr/local/svn # how to authenticate a user AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/users/file # only authenticated users may access the repository Require valid-user </Location>
有時候，你不需要這樣嚴密，舉個例子，Subversion自己在http://svn.collab.net/repos/svn的原始碼允許全世界的人執行版本庫的只讀操作(例如檢出我們的工作副本和使用瀏覽器瀏覽版本庫)，但是限定只有認證用戶可以執行寫操作。為了執行特定的限制，你可以使用Limit和LimitExcept設定指示，就像Location指示，這個區塊有開始和結束標籤，你需要在<Location>中新增這個指示。
在Limit和LimitExcept中使用的參數是可以被這個區塊影響的HTTP請求類型，舉個例子，如果你希望禁止所有的版本庫訪問，只是保留當前支持的只讀操作，你可以使用LimitExcept指示，並且使用GET，PROPFIND，OPTIONS和REPORT請求類型參數，然後前面提到過的Require valid-user指示將會在<LimitExcept>區塊中而不是在<Location>區塊。
<Location /svn>
DAV svn
SVNParentPath /usr/local/svn
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
# For any operations other than these, require an authenticated user.
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
這裡只是一些簡單的例子，想看關於Apache訪問控制Require指示的更深入訊息，可以查看Apache文件中的教程集http://httpd.apache.org/docs-2.0/misc/tutorials.html中的Security部分。
也可以使用Apache的httpd模塊mod_authz_svn更加細緻的設定訪問權限，這個模塊收集客戶端傳遞過來的不同的晦澀的URL訊息，詢問mod_dav_svn來解碼，然後根據在設定文件定義的訪問政策來裁決請求。
如果你從原始碼建立Subversion，mod_authz_svn會自動附加到mod_dav_svn，許多二進制分發版本也會自動安裝，為了驗證它是安裝正確，確定它是在httpd.conf的LoadModule指示中的mod_dav_svn後面：
LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so
為了激活這個模塊，你需要設定你的Location區塊的AuthzSVNAccessFile指示，指定保存路徑中的版本庫訪問政策的文件。(一會兒我們將會討論這個文件的格式。)
Apache非常的靈活，你可以從三種模式裡選擇一種來設定你的區塊，作為開始，你選擇一種基本的設定模式。(下面的例子非常簡單；見Apache自己的文件中的認證和授權選項來查看更多的細節。)
最簡單的區塊是允許任何人可以訪問，在這個場景裡，Apache決不會發送認證請求，所有的用戶作為「匿名」對待。
例 6.1. 匿名訪問的設定實例。
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
# our access control policy
AuthzSVNAccessFile /path/to/access/file
</Location>
在另一個極端，你可以設定為拒絕所有人的認證，所有客戶端必須提供證明自己身份的證書，你通過Require valid-user指示來阻止無條件的認證，並且定義一種認證的手段。
例 6.2. 一個認證訪問的設定實例。
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
# our access control policy
AuthzSVNAccessFile /path/to/access/file
# only authenticated users may access the repository
Require valid-user
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
</Location>
第三種流行的模式是允許認證和匿名用戶的組合，舉個例子，許多管理員希望允許匿名用戶讀取特定的版本庫路徑，但希望只有認證用戶可以讀(或者寫)更多敏感的區域，在這個設定裡，所有的用戶開始時用匿名用戶訪問版本庫，如果你的訪問控制策略在任何時候要求一個真實的用戶名，Apache將會要求認證客戶端，為此，你可以同時使用Satisfy Any和Require valid-user指示。
例 6.3. 一個混合認證/匿名訪問的設定實例。
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
# our access control policy
AuthzSVNAccessFile /path/to/access/file
# try anonymous access first, resort to real
# authentication if necessary.
Satisfy Any
Require valid-user
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
</Location>
一旦你已經設定了httpd.conf模版之一，你需要在對應的路徑建立包含訪問規則的文件，在「基於路徑的授權」一節中有描述。
mod_dav_svn模塊做了許多工作來確定你標記為「不可讀」的資料不會因意外而洩露，這意味著需要緊密監控通過svn checkout或是svn update返回的路徑和文件內容，如果這些命令遇到一些根據認證策略不是可讀的路徑，這個路徑通常會被一起忽略，在歷史或者重命名操作時—例如運行一個類似svn cat -r OLD foo.c的命令來操作一個很久以前改過名字的文件 — 如果一個對象的以前的名字檢測到是只讀的，重命令追蹤就會終止。
所有的路徑檢查在有時會非常昂貴，特別是svn log的情況。當檢索一列修訂版本時，伺服器會查看所有修訂版本修改的路徑，並且檢查可讀性，如果發現了一個不可讀路徑，它會從修訂版本的修改路徑中忽略(通常可以使用--verbose選項查看)，並且整個的日誌訊息會被禁止，不必多說，這種影響大量文件修訂版本的操作會非常耗時。這是安全的代價：即使你並沒有設定mod_authz_svn模塊，mod_dav_svn還是會詢問httpd來對所有路徑運行認證檢查，mod_dav_svn模塊沒有辦法知道那個認證模塊被安裝，所以只能要求Apache調用時提供的內容。
在另一方面，也有一個安全艙門允許你用安全特性來交換速度，如果你不是堅持要求有每目錄授權(如不使用 mod_authz_svn和類似的模塊)，你就可以關閉所有的路徑檢查，在你的httpd.conf文件，使用SVNPathAuthz指示：
例 6.4. 禁用所有的路徑檢查
<Location /repos>
DAV svn
SVNParentPath /usr/local/svn
SVNPathAuthz off
</Location>
SVNPathAuthz指示預設是「on」，當設定為「off」時，所有的路徑為基礎的授權都會關閉；mod_dav_svn停止對每個目錄調用授權檢查。
我們已經覆蓋了關於認證和授權的Apache和mod_dav_svn的大多數選項，但是Apache還提供了許多很好的特性。
使用Apache/WebDAV設定Subversion版本庫時一個非常有用的好處是可以用普通的瀏覽器察看最新的版本庫文件，因為Subversion使用URL來鑒別版本庫版本化的資源，版本庫使用的HTTP為基礎的URL也可以直接輸入到Web瀏覽器中，你的瀏覽器會發送一個GET請求到URL，根據訪問的URL是指向一個版本化的目錄還是文件，mod_dav_svn會負責列出目錄列表或者是文件內容。
因為URL不能確定你所希望看到的資源的版本，mod_dav_svn會一直返回最新的版本，這樣會有一些美妙的副作用，你可以直接把Subversion的URL傳遞給文件作為引用，這些URL會一直指向文件最新的材料，當然，你也可以在別的網站作為超鏈使用這些URL。
當瀏覽Subversion版本庫時，web瀏覽器通過從Apache的HTTP GET返回內容中查看Content-Type:頭可以知道如何渲染文件的線索，這個值是一種MIME類型。默認情況下，Apache告訴瀏覽器所有的版本庫文件都是預設的MIME類型，通常是text/plain，這樣有時候會讓人沮喪，如果一個用戶希望版本庫文件能夠更有意義的渲染—例如一個foo.html，在瀏覽時最好能夠按照HTML方式渲染。
為了生效，我們只需要確認你的文件有正確的svn:mime-type設定，這將在「文件內容類型」一節詳細討論，你可以設定的你的客戶端在文件首次新增到版本庫時自動附加svn:mime-type屬性；見「自動設定屬性」一節。
所以在我們的例子中，如果一個人對foo.html將svn:mime-type設定為text/html，Apache就會告知瀏覽器使用HTML方式渲染文件，也可以給圖片文件設定合適的image/*類型，這樣最終可以使整個web站點直接從版本庫瀏覽，這樣做通常沒有問題，只要你的站點不包含動態生成的內容。
你通常會在版本化的文件的URL之外得到更多地用處—畢竟那裡是有趣的內容存在的地方，但是你會偶爾瀏覽一個Subversion的目錄列表，你會很快發現展示列表生成的HTML非常基本，並且一定沒有在外觀上(或者是有趣上)下功夫，為了自行定義這些目錄顯示，Subversion提供了一個XML目錄特性，一個單獨的SVNIndexXSLT指示在你的httpd.conf文件版本庫的Location塊裡，它將會指導mod_dav_svn在顯示目錄列表的時候生成XML輸出，並且引用你選擇的XSLT樣式表文件：
<Location /svn> DAV svn SVNParentPath /usr/local/svn SVNIndexXSLT "/svnindex.xsl" … </Location>
使用SVNIndexXSLT指示和建立一個XSLT樣式表，你可以讓你的目錄列表的顏色模式與你的網站的其它部分匹配，否則，如果你願意，你可以使用Subversion源分發版本中的tools/xslt/目錄下的範例樣式表。記住提供給SVNIndexXSLT 指示的路徑是一個URL路徑—瀏覽器需要閱讀你的樣式表來利用它們！
因為Apache的核心是一個HTTP伺服器，它包含了夢幻般靈活的日誌特性。各種設定日誌的方式可以超出了本書的範圍，但是我們必須指出，即使是最原始的文件httpd.conf也可以讓Apache產生兩個日誌：error_log和access_log。這些日誌會出現在不同的地方，但通常是建立在Apache安裝的日誌區。(在Unix下，這個目錄是/usr/local/apache2/logs/。)
error_log描述了所有Apache運行中的內部錯誤，access_log記錄了Apache接收到的所有HTTP請求，這個日誌很容易查看，例如包括Subversion客戶端的IP地址，哪些用戶正確認證和請求成功還是失敗。
不幸的是，因為HTTP是無狀態協議，即使最簡單的Subversion客戶端操作會產生多個網路請求，很難通過查看access_log來確定用戶的操作—大多數操作看起來像是一系列神秘的PROPPATCH、GET、PUT和REPORT請求。更糟糕的是，許多客戶段操作會發送幾乎完全相同的一系列請求，所以更加難以區分。
mod_dav_svn會成為一個輔助，通過激活「operational logging」屬性，你可以告訴mod_dav_svn建立另外的日誌文件，來描述你的客戶度uan做了哪些高級操作。
為此，你需要利用Apache的CustomLog指示(在Apache自己的文件裡有詳細解釋)指示，請確定在Subversion的Location指示之外設定這個指示。
<Location /svn>
DAV svn
…
</Location>
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION
在這個例子裡，我們告訴Apache在標準的Apachelogs目錄建立一個svn_logfile日誌文件，%t和%u變數會被請求的時間和用戶名代替，關鍵的部分是SVN-ACTION的兩個實例，當Apache看到變數，會將變數的值替代為環境變數SVN-ACTION，這個環境變數的值是mod_dav_svn在檢測到高級客戶段操作時自動設定的。
所以我們不選擇翻譯下面的傳統的access_log文件：
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/vcc/default HTTP/1.1" 207 398 [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/bln/59 HTTP/1.1" 207 449 [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc HTTP/1.1" 207 647 [26/Jan/2007:22:25:29 -0600] "REPORT /svn/calc/!svn/vcc/default HTTP/1.1" 200 607 [26/Jan/2007:22:25:31 -0600] "OPTIONS /svn/calc HTTP/1.1" 200 188 [26/Jan/2007:22:25:31 -0600] "MKACTIVITY /svn/calc/!svn/act/e6035ef7-5df0-4ac0-b811-4be7c823f998 HTTP/1.1" 201 227 …
… 你可以細讀一個更加智能的svn_logfile文件：
[26/Jan/2007:22:24:20 -0600] - list-dir '/' [26/Jan/2007:22:24:27 -0600] - update '/' [26/Jan/2007:22:25:29 -0600] - remote-status '/' [26/Jan/2007:22:25:31 -0600] sally commit r60
Apache作為一個健壯的Web伺服器的許多特性也可以用來增加Subversion的功能性和安全性，Subversion使用Neon與Apache通訊，這是一種一般的HTTP/WebDAV庫，可以支持SSL(Secure Socket Layer，將在後面討論)。如果你的Subversion是以支持SSL(安全套接層，過一會兒討論)編譯，則你可以使用https://訪問Apache伺服器。
同樣有用的是Apache和Subversion關係的一些特性，像可以指定自行定義的埠號(而不是預設的HTTP的80)或者是一個Subversion可以被訪問的虛擬主機名，或者是通過HTTP代理伺服器訪問的能力，這些特性都是Neon所支持的，所以Subversion輕易得到這些支持。
最後，因為mod_dav_svn是使用一個半完成的WebDAV/DeltaV方言，所以通過第三方的DAV客戶端訪問也是可能的，幾乎所有的現代操作系統(Win32、OS X和Linux)都有把DAV伺服器影射為普通的網路「共享」的內建能力，這是一個複雜的主題；察看附錄 C, WebDAV 和自動版本來得到更多細節。