As we mentioned earlier, each directory of a Subversion
working copy contains a special subdirectory called
.svn which houses administrative data about
that working copy directory. Subversion uses the information in
.svn to keep track of things like:
Which repository location(s) are represented by the files and subdirectories in the working copy directory.
What revision of each of those files and directories are currently present in the working copy.
Any user-defined properties that might be attached to those files and directories.
Pristine (un-edited) copies of the working copy files.
While there are several other bits of data stored in the
.svn directory, we will examine only a
couple of the most important items.
Perhaps the single most important file in the
.svn directory is the
entries file. The entries file is an XML
document which contains the bulk of the administrative
information about a versioned resource in a working copy
directory. It is this one file which tracks the repository
URLs, pristine revision, file checksums, pristine text and
property timestamps, scheduling and conflict state
information, last-known commit information (author, revision,
timestamp), local copy history—practically everything
that a Subversion client is interested in knowing about a
versioned (or to-be-versioned) resource!
The following is an example of an actual entries file:
Example 8.4. Contents of a Typical
<?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>
As you can see, the entries file is essentially a list of
entry tag represents one of
three things: the working copy directory itself (called the
“this directory” entry, and noted as having an
empty value for its
attribute), a file in that working copy directory (noted by
kind attribute set to
"file"), or a subdirectory in that working
kind here is set to
"dir"). The files and subdirectories whose
entries are stored in this file are either already under
version control, or (as in the case of the file named
zeta above) are scheduled to be added to
version control when the user next commits this working copy
directory's changes. Each entry has a unique name, and each
entry has a node kind.
Developers should be aware of some special rules that
Subversion uses when reading and writing its
entries files. While each entry has a
revision and URL associated with it, note that not every
entry tag in the sample file has explicit
url attributes attached to it.
Subversion allows entries to not explicitly store those two
attributes when their values are the same as (in the
revision case) or trivially
url case) the data stored
in the “this directory” entry. Note also that
for subdirectory entries, Subversion stores only the crucial
attributes—name, kind, url, revision, and schedule. In
an effort to reduce duplicated information, Subversion
dictates that the method for determining the full set of
information about a subdirectory is to traverse down into that
subdirectory, and read the “this directory” entry
from its own
.svn/entries file. However,
a reference to the subdirectory is kept in its parent's
entries file, with enough information to
permit basic versioning operations in the event that the
subdirectory itself is actually missing from disk.
As mentioned before, the
directory also holds the pristine “text-base”
versions of files. Those can be found in
.svn/text-base. The benefits of these
pristine copies are multiple—network-free checks for
local modifications and difference reporting, network-free
reversion of modified or missing files, smaller transmission
of changes to the server—but comes at the cost of having
each versioned file stored at least twice on disk. These
days, this seems to be a negligible penalty for most files.
However, the situation gets uglier as the size of your
versioned files grows. Some attention is being given to
making the presence of the “text-base” an option.
Ironically though, it is as your versioned files' sizes get
larger that the existence of the “text-base”
becomes more crucial—who wants to transmit a huge file
across a network just because they want to commit a tiny
change to it?
Similar in purpose to the “text-base” files
are the property files and their pristine
“prop-base” copies, located in
.svn/prop-base respectively. Since
directories can have properties, too, there are also
.svn/dir-prop-base files. Each of these
property files (“working” and “base”
versions) uses a simple “hash-on-disk” file
format for storing the property names and values.
 That is, the URL for the entry is the same as the concatenation of the parent directory's URL and the entry's name.