### 進入工作拷貝的管理區 像我們前面提到的，每個Subversion工作拷貝包含了一個特別的子目錄叫做`.svn`，這個目錄包含了關于工作拷貝目錄的管理數據，Subversion使用`.svn`中的信息來追蹤如下的數據： - 工作拷貝中展示的目錄和文件在版本庫中的位置。 - 工作拷貝中當前展示的文件和目錄的修訂版本。 - 所有附加在文件和目錄上的用戶定義屬性。 - 初始（未編輯）的工作拷貝文件的拷貝。 然而`.svn`目錄中還有一些其他的數據，我們會考察一些最重要的項目。 ### 條目文件 或許`.svn`目錄中最重要的單個文件就是`entries`了，這個條目文件是一個XML文檔，包含了關于工作拷貝中的版本化的資源的大多數管理性信息，這個文件保留了版本庫URL、原始修訂版本、可知的最后提交信息（作者、修訂版本和時間戳）和本地拷貝歷史―實際上是Subversion客戶端關于一個版本化（或者是將要版本化的）資源的所有感興趣的信息！ **比較Subversion和CVS的管理區域** 掃視一下典型的`.svn`目錄會發現比CVS在`CVS`目錄中的內容多一些，`entries`文件包含的XML描述了工作拷貝目錄的當前狀態，而且基本上合并了CVS的`Entries`、`Root`和`Repository`的功能。 如下是一個實際條目文件的例子： **例8.4.典型的`.svn/entries`文件內容** ~~~ <xml version="1.0" encoding="utf-8"> <wc-entries xmlns="svn:"> <entry committed-rev="1" name="" committed-date="2002-09-24T17:12:44.064475Z" url="http://svn.red-bean.com/tests/.greek-repo/A/D" kind="dir" revision="1"/> <entry committed-rev="1" name="gamma" text-time="2002-09-26T21:09:02.000000Z" committed-date="2002-09-24T17:12:44.064475Z" checksum="QSE4vWd9ZM0cMvr7/+YkXQ==" kind="file" prop-time="2002-09-26T21:09:02.000000Z"/> <entry name="zeta" kind="file" schedule="add" revision="0"/> <entry url="http://svn.red-bean.com/tests/.greek-repo/A/B/delta" name="delta" kind="file" schedule="add" revision="0"/> <entry name="G" kind="dir"/> <entry name="H" kind="dir" schedule="delete"/> </wc-entries> ~~~ 就像你能看到的，條目文件本質上是一列條目，每個`entry`標簽代表了下面三者之一的事情：工作拷貝目錄本身（叫做“本目錄”條目，并且*`name`*屬性的值為空），工作拷貝目錄中的一個文件（通過*`kind`*屬性設置為`"file"`來標示），或者是工作拷貝中的一個子目錄（*`kind`*這時設置為`"dir"`）。所有在這個文件標記的文件和子目錄都是已經納入版本控制或者是（上面例子中的`zeta`）預定在下次提交加入到版本控制。每個條目都有一個唯一的名字，每個條目有一個kind節點。 開發者必須意識到一些Subversion讀寫`entries`文件的特殊規則，每個條目都有一個修訂版本和URL與之關聯，注意在上面實例文件中并不是每個`entry`標簽都有明確的*`revision`*或*`url`*屬性，Subversion允許一些情況不明確的說明這個兩個屬性，如屬性值與“本目錄”的值相同（*`revision`*的情況）或者是可以從“本目錄”簡單計算出的來（*`url`*）。注意對于子目錄條目，Subversion只保管最重要的信息―名稱、類型、URL、修訂版本和日程。為了減少重復信息，Subversion指示當要檢測目錄信息時會跑到這個子目錄自己的`.svn/entries`的“本目錄”條目。當然了，對這個子目錄的引用還是會保存在父目錄的`entries`文件，這些信息足以在子目錄丟失后執行基本的版本操作。 ### 原始拷貝和屬性文件 如我們前面提到的，`.svn`也包含了一些原始的“text-base”文件版本，可以在`.svn/text-base`看到。這些原始文件的好處是多方面的―察看本地修改和區別不需要經過網絡訪問，減少傳遞修改時的數據―但是隨之而來的代價是每個版本化的文件都在磁盤至少保存兩次，現在看來這是對大多數文件可以忽略不計的一個懲罰。但是，當你版本控制的文件增多之后形勢會變得很嚴峻，我們已經注意到了應該可以選擇使用“text-base”，但是具有諷刺意味的是，當版本化文件增大時，“text-base”文件的存在會更加重要―誰會希望在提交一個小修改時在網絡上傳遞一個大文件？ 同“text-base”文件的用途一樣的還有屬性文件和它們的“prop-base”拷貝，分別位于`.svn/props`和`.svn/prop-base`。因為目錄也有屬性，所以也有`.svn/dir-props`和`.svn/dir-prop-base`文件。所有的屬性文件（“working”和“base”版本）都使用同樣的“hash-on-disk”文件格式來排序屬性名稱和值。 也就是，這個條目的URL就是父目錄與名稱合并。