进入工作拷贝的管理区

### 进入工作拷贝的管理区 像我们前面提到的，每个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`文件内容** ~~~ ~~~ 就像你能看到的，条目文件本质上是一列条目，每个`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就是父目录与名称合并。