### 網絡模型 這部分是討論了Subversion客戶端和服務器怎樣互相交流，不考慮具體使用的網絡實現，通過閱讀，你會很好的理解服務器的行為方式和多種客戶端與之響應的配置方式。 ### 請求和響應 Subversion客戶端花費大量的時間來管理工作拷貝，當它需要版本庫信息，它會做一個網絡請求，然后服務器給一個恰當的回答，具體的網絡協議細節對用戶不可見，客戶端嘗試去訪問一個URL，根據URL模式的不同，會使用特定的協議與服務器聯系（見[版本庫的URL]( "版本庫的URL")），用戶可以運行**svn --version**來查看客戶端可以使用的URL模式和協議。 當服務器處理一個客戶端請求，它通常會要求客戶端確定它自己的身份，它會發出一個認證請求給客戶端，而客戶端通過提供*憑證*給服務器作為響應，一旦認證結束，服務器會響應客戶端最初請求的信息。注意這個系統與CVS之類的系統不一樣，它們會在請求之前，預先提供憑證（“logs in”）給服務器，在Subversion里，服務器通過請求客戶端適時地“拖入”憑證，而不是客戶端“推”出。這使得這種操作更加的優雅，例如，如果一個服務器配置為世界上的任何人都可以讀取版本庫，在客戶使用**svn checkout**時，服務器永遠不會發起一個認證請求。 如果客戶端請求往版本庫寫入新的數據（例如**svn commit**），這會建立新的修訂版本樹，如果客戶端的請求是經過認證的，認證過的用戶的用戶名就會作為`svn:author`屬性的值保存到新的修訂本里（見[“未受版本控制的屬性”一節]( "未受版本控制的屬性")）。如果客戶端沒有經過認證（換句話說，服務器沒有發起過認證請求），這時修訂本的`svn:author`的值是空的。 ### 客戶端憑證緩存 許多服務器配置為在每次請求時要求認證，這對一次次輸入用戶名和密碼的用戶來說是非常惱人的事情。 令人高興的是，Subversion客戶端對此有一個修補：存在一個在磁盤上保存認證憑證緩存的系統，缺省情況下，當一個命令行客戶端成功的在服務器上得到認證，它會保存一個認證文件到用戶的私有運行配置區―類Unix系統下會在`~/.subversion/auth/`，Windows下在`%APPDATA%/Subversion/auth/`（運行區在[“運行配置區”一節]( "運行配置區")會有更多細節描述）。成功的憑證會緩存在磁盤，以主機名、端口和認證域的組合作為唯一性區別。 當客戶端接收到一個認證請求，它會首先查找磁盤中的認證憑證緩存，如果沒有發現，或者是緩存的憑證認證失敗，客戶端會提示用戶需要這些信息。 十分關心安全的人們一定會想“把密碼緩存在磁盤？太可怕了，永遠不要這樣做！”但是請保持冷靜，首先，`auth/`是訪問保護的，只有用戶（擁有者）可以讀取這些數據，不是整個世界，如果這對你還不夠安全，你可以關閉憑證緩存，只需要一個簡單的命令，使用參數`--no-auth-cache`： ~~~ $ svn commit -F log_msg.txt --no-auth-cache Authentication realm: <svn://host.example.com:3690> example realm Username: joe Password for 'joe': Adding newfile Transmitting file data . Committed revision 2324. # password was not cached, so a second commit still prompts us $ svn delete newfile $ svn commit -F new_msg.txt Authentication realm: <svn://host.example.com:3690> example realm Username: joe [...] ~~~ 或許，你希望永遠關閉憑證緩存，你可以編輯你的運行`配置`文件（坐落在`auth/`目錄），只需要把`store-auth-creds`設置為`no`，這樣就不會有憑證緩存在磁盤。 ~~~ [auth] store-auth-creds = no ~~~ 有時候，用戶希望從磁盤緩存刪除特定的憑證，為此你可以瀏覽到`auth/`區域，刪除特定的緩存文件，憑證都是作為一個單獨的文件緩存，如果你打開每一個文件，你會看到鍵和值，`svn:realmstring`描述了這個文件關聯的特定服務器的域： ~~~ $ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 joe K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domain.com:443> Joe's repository END ~~~ 一旦你定位了正確的緩存文件，只需要刪除它。 客戶端認證的行為的最后一點：對使用`--username`和`--password`選項的一點說明，許多客戶端和子命令接受這個選項，但是要明白使用這個選項*不會*主動地發送憑證信息到服務器，就像前面討論過的，服務器會在需要的時候才會從客戶端“拖”入憑證，客戶端不會隨意“推”出。如果一個用戶名和/或者密碼作為選項傳入，它們*只會*在服務器需要時展現給服務器。通常，只有在如下情況下才會使用這些選項： - 用戶希望使用與登陸系統不同的名字認證，或者 - 一段不希望使用緩存憑證但需要認證的腳本 這里是Subversion客戶端在收到認證請求的時候的行為方式： 1. 檢查用戶是否通過`--username`和/或`--password`命令選項指定了任何憑證信息，如果沒有，或者這些選項沒有認證成功，然后 1. 查找運行中的`auth/`區域保存的服務器域信息，來確定用戶是否已經有了恰當的認證緩存，如果沒有，或者緩存憑證認證失敗，然后 1. 提示用戶輸入。 如果客戶端通過以上的任何一種方式成功認證，它會嘗試在磁盤緩存憑證（除非用戶已經關閉了這種行為方式，在前面提到過。） 這個問題實際上是一個FAQ，源自錯誤的服務器配置。 再次重申，一個常見的錯誤是把服務器配置為從不會請求認證，當用戶傳遞`--username`和`--password`給客戶端時，他們驚奇的發現它們沒有被使用，如新的修訂版本看起來始終是由匿名用戶提交的！