进入工作拷贝的管理区

像我们前面提到的,每个Subversion工作拷贝包含了一个特别的子目录叫做.svn,这个目录包含了关于工作拷贝目录的管理数据,Subversion使用.svn中的信息来追踪如下的数据:

然而.svn目录中还有一些其他的数据,我们会考察一些最重要的项目。

条目文件

或许.svn目录中最重要的单个文件就是entries了,这个条目文件是一个XML文档,包含了关于工作拷贝中的版本化的资源的大多数管理性信息,这个文件保留了版本库URL、原始修订版本、可知的最后提交信息(作者、修订版本和时间戳)和本地拷贝历史—实际上是Subversion客户端关于一个版本化(或者是将要版本化的)资源的所有感兴趣的信息!

如下是一个实际条目文件的例子:

例 8.4. 典型的.svn/entries文件内容

<?xml version="1.0" encoding="utf-8"?>
<wc-entries
   xmlns="svn:">
<entry
   committed-rev="1"
   name=""
   committed-date="2005-04-04T13:32:28.526873Z"
   url="http://svn.red-bean.com/repos/greek-tree/A/D"
   last-author="jrandom"
   kind="dir"
   uuid="4e820d15-a807-0410-81d5-aa59edf69161"
   revision="1"/>
<entry
   name="lambda"
   copied="true"
   kind="file"
   copyfrom-rev="1"
   schedule="add"
   copyfrom-url="http://svn.red-bean.com/repos/greek-tree/A/B/lambda"/>
<entry
   committed-rev="1"
   name="gamma"
   text-time="2005-12-11T16:32:46.000000Z"
   committed-date="2005-04-04T13:32:28.526873Z"
   checksum="ada10d942b1964d359e048dbacff3460"
   last-author="jrandom"
   kind="file"
   prop-time="2005-12-11T16:32:45.000000Z"/>
<entry
   name="zeta"
   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标签都有明确的revisionurl属性,Subversion允许一些情况不明确的说明这个两个属性,如属性值与“本目录”的值相同(revision的情况)或者是可以从“本目录”简单计算[46]出的来(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”文件格式来排序属性名称和值。



[46] 也就是,这个条目的URL就是父目录与名称合并。