### 进入工作拷贝的管理区 像我们前面提到的,每个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就是父目录与名称合并。